This page discusses the public access prevention bucket setting and the related public access prevention organization policy constraint. Using either the setting or constraint restricts the entities, such as anonymous users over the internet, that can be granted access to your data. For an overview of access control options, see Overview of access control.
Public access prevention protects Cloud Storage buckets and objects from being accidentally exposed to the public. When you enforce public access prevention, no one can make data in applicable buckets public through IAM policies or ACLs. There are two ways to enforce public access prevention:
You can enforce public access prevention on individual buckets.
If your bucket is contained within an organization, you can enforce public access prevention by using the organization policy constraint
storage.publicAccessPreventionat the project, folder, or organization level.
Should you use public access prevention?
Use public access prevention if you know your data should never be exposed on the public internet. To provide the most security to your resources, enforce public access prevention at the highest possible level of your organization.
You should not use public access prevention if you need to keep the bucket public for use cases such as static website hosting. To make exceptions for such buckets in organizations that otherwise enforce public access prevention, disable public access prevention on the specific project that contains the bucket.
Behavior when enforced
Resources subject to public access prevention have the following behavior:
Requests to buckets and objects authorized using
allAuthenticatedUsersfail with an HTTP
Existing IAM policies and ACLs granting access to
allAuthenticatedUsersremain in place but are overridden by public access prevention.
Requests to create buckets or objects with
allAuthenticatedUsersin their IAM policies or ACLs fail, with the following exception:
- If a bucket has a default object ACL containing
allUsers, requests to create objects in that bucket succeed. The ACLs for such objects contain
allUsersis overridden by public access prevention.
- If a bucket has a default object ACL containing
Requests to add
allAuthenticatedUsersto an IAM policy or ACL fail with
412 Precondition Failed.
Even if a bucket does not have public access prevention explicitly enforced in
its settings, it might still inherit public access prevention, which occurs
if the organization policy constraint
set on the project, folder, or organization that the bucket exists within. For
this reason, the bucket state can only be set to
If the bucket state is
unspecified, the bucket inherits its state from the
parent project. Similarly, the project, by default, inherits its public access
prevention state from the folder or organization it exists within. However, you
can explicitly set
storage.publicAccessPrevention to be enabled or disabled
for the project, which overrides any value that would otherwise be inherited.
For example, setting
storage.publicAccessPrevention for a project to disabled
guarantees that buckets within the project that have an
don't use public access prevention, regardless of the public access prevention
state at the folder or organization levels.
Behavior if disabled
When public access prevention no longer applies for a resource, the following occurs:
Existing IAM policies and ACLs that grant access to
allAuthenticatedUserstake effect and make data accessible to the public.
Requests to create IAM policies or ACLs that allow access to
An object created under public access prevention without public ACLs may become accessible to the public if it was created in a publicly accessible bucket.
You can disable public access prevention for a project, folder, or organization
at any time. Buckets with an
enforced setting continue to have public access
prevention enforced, even if you disable it for a project, folder, or
organization that contains the bucket.
IAM permissions for public access prevention
To manage the public access prevention organization policy at the project,
folder, or organization level, you need the IAM
permission. This permission can be found in the
To manage the public access prevention setting on a bucket, you need both the
permissions. These permissions can be found in the
If the bucket's parent project has public access prevention enforced through an organization policy, Storage Admins can't exempt the bucket from public access prevention.
When you enforce public access prevention on existing resources, all existing authorization and new additions of
allAuthenticatedUsersare blocked. This can affect your buckets in the following ways:
If an application depends on
allAuthenticatedUsersto access your data or create public resources, enabling public access prevention can break the application.
Cloud Audit Logs does not track access to objects that are public. If Data Access logs are enabled when you enforce public access prevention, you might see an increase in log generation, which count towards your log ingestion quota and can incur Cloud Audit Logs charges. This increase might occur because access that previously was public and unlogged could become associated with specific authorizations, which is logged.
Signed URLs, which give time limited, narrowly-scoped access to anyone who uses them, are not affected by public access prevention.
Projects not associated with an organization cannot use organization policies. Buckets within such a project should use the bucket-level setting.
Public access prevention is strongly consistent for reading-after-update, but enforcement can take up to 10 minutes to take effect.
After enforcement begins, your objects might still be publicly accessible through an internet cache for some amount of time, depending on the objects'
Cache-Controlsetting. For example, if the
Cache-Control:max-agefor an object is set to the default of 3600 seconds, the object might persist in an internet cache for that amount of time.