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:
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
and
allAuthenticatedUsers
fail with an HTTP
401
or
403
status code.
Existing IAM policies and ACLs granting access to
allUsers
and
allAuthenticatedUsers
remain in place but are overridden by public
access prevention.
Requests to create buckets or objects with
allUsers
and
allAuthenticatedUsers
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 contain
allUsers
, 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 the
storage.publicAccessPrevention
organization policy constraint:
If
storage.publicAccessPrevention
is set to
True
for the
project
that 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 the
storage.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.publicAccessPrevention
value 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
and
allAuthenticatedUsers
take effect and make data accessible to the public.
Requests to create IAM policies or ACLs that allow access to
allUsers
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.
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-age
for 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