Public Access Prevention and Legacy ACL Evaluation Order

Question

Google Cloud Storage's Public Access Prevention feature is designed to block all public ingress to a bucket and its objects when activated. The service documentation confirms that the flag blocks public access via IAM and ACLs, but it does not specify the evaluation sequence when both the bucket-level prevention flag and legacy ACL entries granting the AllUsers group read permission are present. This creates uncertainty about whether existing ACL entries are automatically overridden, ignored, or remain potentially effective during runtime access checks, particularly for object-level requests.

Administrators relying solely on Public Access Prevention for strict access control may inadvertently leave exposure paths if legacy ACLs are not addressed, especially during bucket migration or policy revisions.

When a bucket has Public Access Prevention enabled and contains an AllUsers ACL entry, which mechanism is consulted first during runtime access checks?
Does enabling Public Access Prevention automatically neutralize or ignore existing AllUsers ACL entries, or must those entries be manually removed to ensure complete public access restriction?
What is the runtime access behavior that definitively confirms public access is blocked regardless of coexisting legacy ACL configurations?

Muntasir · Answer

Direct Answer
During runtime access evaluation, GCP Storage first checks the bucket‑level Public Access Prevention (PAP) flag. If PAP is set to Enforced, the request is denied before any IAM or legacy ACL evaluation, effectively neutralizing any AllUsers ACL entry.

Likely explanation (not yet verified)
The storage service short‑circuits the access path: PAP flag → IAM policy (only if PAP disabled) → Legacy ACLs. This ordering is inferred from documentation stating that PAP “blocks public access via IAM and ACLs,” implying the flag is evaluated first.

Confirmed facts

PAP Enforced blocks all public ingress to the bucket and its objects prior to IAM or ACL checks.
Legacy ACL entries, including an AllUsers read grant, are evaluated only when PAP is disabled.
An AccessDenied error returned for a request that the AllUsers ACL would permit confirms that public access is blocked.

Steps to verify in this case

Retrieve the bucket configuration (e.g., gsutil get bucket -I gs://) and confirm publicAccessPrevention is Enforced.
Perform a test GET request from an identity that only has the AllUsers read permission (for example, a service account bound to the AllUsers IAM role) and verify the response is AccessDenied.

Consideration
If Uniform Bucket‑Level Access (UBL) is enabled, ACL evaluation is bypassed, which would change the effective order. To ensure complete restriction you must also confirm that no IAM bindings grant roles to allUsers or allAuthenticated.
Is Uniform Bucket‑Level Access (UBL) enabled on the bucket?

Public Access Prevention and Legacy ACL Evaluation Order

1 answer

Direct Answer

Likely explanation (not yet verified)

Confirmed facts

Steps to verify in this case

Consideration

Your perspective belongs here.

0 question comments