Public access prevention (original) (raw)

Setup

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.

Overview

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 constraintstorage.publicAccessPrevention at theproject, 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 allUsers andallAuthenticatedUsers fail with an HTTP 401 or 403 status code.
• Existing IAM policies and ACLs granting access to allUsersand allAuthenticatedUsers remain in place but are overridden by public access prevention.
• Requests to create buckets or objects with allUsers andallAuthenticatedUsers in 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 containallUsers, but allUsers is overridden by public access prevention.
• Requests to add allUsers and allAuthenticatedUsers to an IAM policy or ACL fail with 412 Precondition Failed.

Inheritance

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 storage.publicAccessPrevention is set on the project, folder, or organization that the bucket exists within. For this reason, the bucket state can only be set to enforced or inherited.

• If a bucket's public access prevention metadata is set to enforced, then public access prevention applies for the bucket.
• If a bucket's public access prevention metadata is set to inherited, then public access prevention is determined by thestorage.publicAccessPrevention organization policy constraint:
  • If storage.publicAccessPrevention is set to True for the projectthat contains the bucket, then public access prevention applies to the bucket.
  • If storage.publicAccessPrevention is set to False for the project that contains the bucket, then public access prevention does not apply to the bucket.
  • If storage.publicAccessPrevention is not set for the project that contains the bucket, then public access prevention is determined by thestorage.publicAccessPrevention value set by the folder, if any, that contains the project.
    * Similarly, if the folder containing the bucket also does not set any value for storage.publicAccessPrevention, then public access prevention is determined by the storage.publicAccessPreventionvalue set by the organization that contains the project.
    * If storage.publicAccessPrevention is not set for any resource, then public access prevention does not apply to the bucket.

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 allUsers andallAuthenticatedUsers take effect and make data accessible to the public.
• Requests to create IAM policies or ACLs that allow access toallUsers and allAuthenticatedUsers succeed.
• 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.

Considerations

• When you enforce public access prevention on existing resources, all existing authorization and new additions of allUsers and allAuthenticatedUsers are blocked. This can affect your buckets in the following ways:
  • If an application depends on allUsers and allAuthenticatedUsers to access your data or create public resources, enabling public access prevention can break the application. For information about how to identify your public resources that other applications might be depending on, expand the following content:

  How to identify public resources

  Before you enforce public access prevention, we recommend that you take inventory of your public resources to make sure you don't break other workloads that have a dependency on your data being public. You can locate buckets, objects, and managed folders that are public by using the following methods:
  * To help identify workloads that might be accessing your public data,set up usage logs, which can provide information about data access requests made to public resources.
  * To determine if a bucket might be accessible to the public,check the bucket's IAM policies. Policies that grant roles to the principal allUsers orallAuthenticatedUsers make the bucket potentially accessible to the public. As an alternative to getting the IAM policy for individual buckets, you can use Cloud Asset Inventory to view the policies for all buckets in a project, folder, or organization.
  If there are managed folders in your bucket, you might also want tocheck the IAM policies of the managed folders to identify which managed folders might be accessible to the public.
  * To determine if individual objects might be accessible to the public,check the object for ACLs. ACLs that grant access to the principal allUsers orallAuthenticatedUsers make the object potentially accessible to the public.

  • 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-Control setting. 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.

What's next

• Learn how to use public access prevention.
• Read more about organization policies.