Organization policy constraints for Cloud Storage

Stay organized with collections Save and categorize content based on your preferences.

This page provides supplemental information about organization policy constraints that apply to Cloud Storage. Use constraints to enforce bucket and object behaviors across an entire project or organization.

Cloud Storage constraints

The following constraints can be applied to an organization policy and relate to Cloud Storage:

Enforce public access prevention

API Name: constraints/storage.publicAccessPrevention

When you apply the publicAccessPrevention constraint on a resource, public access is restricted for all buckets and objects, both new and existing, under that resource.

Note that enabling or disabling publicAccessPrevention may take up to 10 minutes to go into effect.

Retention policy duration in seconds

API Name: constraints/storage.retentionPolicySeconds

When you apply the retentionPolicySeconds constraint, you specify one or more durations as part of the constraint. Once set, bucket retention policies must include one of the specified durations. retentionPolicySeconds is required with new bucket creation or when adding/updating the retention period of a pre-existing bucket; however, it's not otherwise required on pre-existing buckets.

If you set multiple retentionPolicySeconds constraints at different resource levels, they are enforced hierarchically. For this reason, it's recommended that you set the inheritFromParent field to true, which ensures that policies at higher layers are also considered.

Require uniform bucket-level access

API Name: constraints/storage.uniformBucketLevelAccess

When you apply the uniformBucketLevelAccess constraint, new buckets must enable the uniform bucket-level access feature, and pre-existing buckets with this feature enabled cannot disable it. Pre-existing buckets with uniform bucket-level access disabled are not required to enable it.

Detailed audit logging mode

API Name: constraints/gcp.detailedAuditLoggingMode

When you apply the detailedAuditLoggingMode constraint, Cloud Audit Logs logs associated with Cloud Storage operations contain detailed request and response information. This constraint is recommended to be used in conjunction with Bucket Lock when seeking various compliances such as SEC Rule 17a-4(f), CFTC Rule 1.31(c)-(d), and FINRA Rule 4511(c).

Logged information includes query parameters, path parameters, and request body parameters. Logs exclude certain parts of requests and responses that are associated with sensitive information. For example, logs exclude:

  • Credentials, such as Authorization, X-Goog-Signature, or upload-id.
  • Encryption key information, such as x-goog-encryption-key.
  • Raw object data.

When using this constraint, note the following:

  • Detailed request and response information is not guaranteed; in rare cases, empty logs might be returned.

  • Enabling detailedAuditLoggingMode increases the amount of data stored in audit logs, which could affect your Cloud Logging charges for Data Access logs.

  • Enabling or disabling detailedAuditLoggingMode takes up to 10 minutes to go into effect.

  • Logged requests and responses are recorded in a generic format that matches the field names of the JSON API.

Restrict authentication types

API Name: constraints/storage.restrictAuthTypes

When you apply the restrictAuthTypes constraint, requests to access Cloud Storage resources using the restricted authentication type fail, regardless of the validity of the request. This constraint is recommended when you need to meet regulatory requirements or increase the security of your data.

The following authentication types can be restricted:

  • USER_ACCOUNT_HMAC_SIGNED_REQUESTS: Restricts requests signed by user account HMAC keys.

  • SERVICE_ACCOUNT_HMAC_SIGNED_REQUESTS: Restricts requests signed by service account HMAC keys.

  • in:ALL_HMAC_SIGNED_REQUESTS: Restrict requests signed by either user account or service account HMAC keys. If you need to meet data sovereignty requirements, it's recommended that you restrict all HMAC signed requests.

When you enable this constraint, the following occurs:

  • Cloud Storage restricts access for requests that are authenticated with the restricted authentication type. Requests fail with the error 403 Forbidden.

  • Entities that were previously authorized to perform the request receive an error message explaining that the authentication type is disabled.

  • If HMAC keys are restricted:

    • HMAC keys of the restricted type can no longer be created or activated in the resource that the constraint is enforced upon. Requests to create or activate HMAC keys fail with the error 403 Forbidden.

    • Existing HMAC keys remain but are no longer usable. They can be deactivated or deleted, but cannot be reactivated.

When using the restrictAuthTypes constraint, be aware of existing resources that depend on HMAC authentication. For example, if you migrated from Amazon Simple Storage Service (Amazon S3), your application likely uses HMAC keys to authenticate requests to Cloud Storage. You can use the Cloud Monitoring metric to track the number of times HMAC keys have been used to authenticate requests.

Require the use of customer-managed encryption keys (CMEK)

API Name: constraints/gcp.restrictNonCmekServices

When you apply the restrictNonCmekServices constraint, you define the services whose resources require the use of customer-managed encryption keys. You can apply this constraint to Cloud Storage objects or buckets by adding to the list of restricted services with the constraint set to Deny. If subject to the constraint, Cloud Storage objects must be written using a Cloud KMS key, which is either specified in the request or set as the default encryption key for the destination bucket. Cloud Storage buckets must have a Cloud KMS key set as the default encryption key.

If you attempt to write an object or create a bucket that's not encrypted by a Cloud KMS key, you receive the following error message: "A customer-managed encryption key (CMEK) is required by an org policy in effect. Either set a default CMEK on the bucket or specify a CMEK in your request."

When using this constraint, note the following:

  • Enabling restrictNonCmekServices might cause breaking changes if you write into a bucket without a default Cloud KMS key or exclude a Cloud KMS key in your request.

  • Existing buckets that don't have a default Cloud KMS key are unaffected by the constraint. However, if you set a Cloud KMS key on an existing bucket while the constraint is enabled, that bucket becomes subject to the constraint.

  • Existing objects encrypted with Google-managed encryption keys or customer-supplied encryption keys are not subject to this constraint. Future rewrites of such objects, however, are subject to the constraint.

  • Changes to constraints/gcp.restrictNonCmekServices take up to 10 minutes to go into effect.

For more information about this constraint, see CMEK organization policies.

Restrict projects with a valid customer-managed encryption key (CMEK)

API Name: constraints/gcp.restrictCmekCryptoKeyProjects

When you apply the restrictCmekCryptoKeyProjects constraint, you define the projects from which a Cloud KMS key can be used in requests. When you apply this constraint:

  • Any Cloud KMS key specified in a request must come from a project that's allowed by the organization policy.

  • If you create a new bucket, any Cloud KMS key you set on the bucket must come from an allowed project.

  • Object writes and updates fail for existing buckets that have an invalid Cloud KMS key. You must change the bucket's default Cloud KMS key to a key that comes from an allowed project, or remove the Cloud KMS from the bucket. Note that you cannot remove a Cloud KMS key from a bucket when the restrictNonCmekServices constraint is enabled.

If you attempt to specify a Cloud KMS key in a request that doesn't come from an allowed project, you receive the following error message: "The specified key cannot be used because its project is restricted by an org policy. Try again with a customer-managed encryption key (CMEK) from an allowed project."

If you attempt to write into a bucket with a Cloud KMS key that doesn't come from an allowed project, you receive the following error message: "The bucket uses a default key from a project that is restricted by an org policy in effect. Either set an allowed customer-managed encryption key (CMEK) as the default for the bucket or specify an allowed CMEK in your request."

When using this constraint, note the following:

  • Existing objects are not subject to this constraint.

  • This constraint alone does not enforce the use of customer-managed encryption keys from allowed projects. To enforce the use of customer-managed encryption keys from allowed projects, you must apply both the constraints/gcp.restrictNonCmekServices and constraints/gcp.restrictCmekCryptoKeyProjects constraints.

  • Changes to constraints/gcp.restrictCmekCryptoKeyProjects take up to 10 minutes to go into effect.

For more information about this constraint, see CMEK organization policies.

What's next