Cloud Storage bucket public access needs review

Review public Cloud Storage permissions and limit access to the required buckets, objects and operations.

Description

Cloud Storage's allUsers includes anonymous users, and allAuthenticatedUsers includes a broad set of authenticated accounts beyond any one organization. Granting permissions to these principals can allow unintended users to access buckets or objects. The permitted operations depend on the assigned role and applicable access controls.

Omitted ACL settings alone do not establish public access. Initial default ACLs provide project-private access, while IAM can grant permissions separately. Uniform bucket-level access disables ACL authorization. Public access prevention limits the effect of permissions granted to public principals.

Potential impact

  • Public read permission on an object can expose its data. A bucket's READER permission allows operations such as listing objects; it does not by itself grant permission to read every object's contents.
  • Public bucket write permissions can allow objects to be created, replaced or deleted. Check which permissions are actually granted.
  • Public permissions in a default object ACL can affect new objects that receive that ACL. Changing the default does not update existing object ACLs, which need separate review.

Remediation

  • Remove unnecessary allUsers or allAuthenticatedUsers grants from bucket ACLs, object ACLs, default object ACLs and IAM. Allow only the required users, groups or service accounts to perform the necessary operations.
  • Configure permissions for the chosen access-control model. If uniform bucket-level access is enabled, manage permissions through IAM without relying on ACLs.
  • Consider public access prevention where public access is unnecessary. First check for services that depend on public content. After the change, verify existing object permissions and legitimate application access.

ACL configuration examples

These incomplete excerpts compare permission recipients. Ansible google.cloud 1.14.0 expects ACLs as lists of dictionaries and each entry's bucket as a dictionary reference; the excerpts use objects and strings instead. The ACL bucket references also differ from the bucket name in the module's name, and some entries omit role. Correct these formats, references and required roles before applying a configuration.

Public principals

yaml
- name: create a bucket1
  google.cloud.gcp_storage_bucket:
    name: ansible-storage-module1
    project: test_project
    auth_kind: serviceaccount
    service_account_file: "/tmp/auth.pem"
    state: present
    default_object_acl:
      bucket: bucketName1
      entity: allUsers
      role: READER

- name: create a bucket2
  google.cloud.gcp_storage_bucket:
    name: ansible-storage-module2
    project: test_project
    auth_kind: serviceaccount
    service_account_file: "/tmp/auth.pem"
    state: present
    acl:
      bucket: bucketName2
      entity: allAuthenticatedUsers

Group principal

yaml
- name: create a bucket
  google.cloud.gcp_storage_bucket:
    name: ansible-storage-module
    project: test_project
    auth_kind: serviceaccount
    service_account_file: /tmp/auth.pem
    state: present
    acl:
      bucket: bucketName
      entity: group-example@googlegroups.com

Explanation:

  • Public principals: The first task specifies allUsers in the default ACL for new objects. The second specifies allAuthenticatedUsers in the bucket ACL. Review the target resource together with the assigned role.
  • Group principal: group-example@googlegroups.com identifies a group. Verify its membership and grant only the required role. Naming a group does not remove public permissions granted through other ACLs or IAM.

References