Apply a CMEK organization policy

Google Cloud offers two organization policy constraints to help ensure CMEK usage across an organization:

  • constraints/gcp.restrictNonCmekServices is used to require CMEK protection.
  • constraints/gcp.restrictCmekCryptoKeyProjects is used to limit which Filestore keys are used for CMEK protection.

CMEK organization policies only apply to newly created resources within supported Google Cloud services.

For a more detailed explanation of how this works, see Google Cloud resource hierarchy and CMEK organization policies.

Control CMEK use with organization policy

Filestore integrates with CMEK organization policy constraints to let you specify encryption compliance requirements for Filestore resources in your organization.

This integration lets you do the following:

The following sections cover both of these tasks.

Require CMEKs for all Filestore resources

A common policy is to require CMEKs to be used to protect all resources in an organization. You can use the constraints/gcp.restrictNonCmekServices constraint to enforce this policy in Filestore.

If set, this organization policy causes all resource creation requests without a specified Cloud KMS key to fail.

After you set this policy, it applies only to new resources in the project. Any existing resources without Cloud KMS keys set continue to exist and are accessible without issue.

Console

  1. Open the Organization policies page.

    Go to Organization policies

  2. In the Filter field, enter constraints/gcp.restrictNonCmekServices, and then click Restrict which services may create resources without CMEK.

  3. Click Manage Policy.

  4. Select Customize, select Replace, and then click Add Rule.

  5. Select Custom, then click Deny.

  6. In the Custom Value field, enter is:file.googleapis.com.

  7. Click Done, and then click Set Policy.

gcloud 

  gcloud resource-manager org-policies --project=PROJECT_ID \
    deny gcp.restrictNonCmekServices is:file.googleapis.com

To verify that the policy is successfully applied, you can try to create an instance or backup in the project. The process fails unless you specify a Cloud KMS key.

Restrict Cloud KMS keys for a Filestore project

You can use the constraints/gcp.restrictCmekCryptoKeyProjects constraint to restrict the Cloud KMS keys that you can use to protect a resource in a Filestore project.

You might specify a rule, for example, "For all Filestore resources in projects/my-company-data-project, Cloud KMS keys used in this project must come from projects/my-company-central-keys OR projects/team-specific-keys."

Console

  1. Open the Organization policies page.

    Go to Organization policies

  2. In the Filter field, enter constraints/gcp.restrictCmekCryptoKeyProjects, and then click Restrict which projects may supply KMS CryptoKeys for CMEK.

  3. Click Manage Policy.

  4. Select Customize, select Replace, and then click Add Rule.

  5. Select Custom, then click Allow.

  6. In the Custom Value field, enter the following:

    under:projects/KMS_PROJECT_ID

    Replace the following:

    • KMS_PROJECT_ID with the project ID where the Cloud KMS keys you want to use are located. For example, under:projects/my-kms-project.

  7. Click Done, and then click Set Policy.

gcloud 

  gcloud resource-manager org-policies --project=PROJECT_ID \
    allow gcp.restrictCmekCryptoKeyProjects under:projects/KMS_PROJECT_ID

Replace the following:

  • KMS_PROJECT_ID with the project ID where the Cloud KMS keys you want to use are located. For example, under:projects/my-kms-project.

To verify that the policy is successfully applied, you can try to create an instance or backup using a Cloud KMS key from a different project. The process will fail.

Limitations

The following limitations apply when setting an organization policy.

CMEK availability

As a reminder, CMEK support is not available for the basic HDD and basic SSD service tiers. Given the way these constraints are defined, if you apply an organization policy that requires CMEK use and then attempt to create a basic-tier instance or backup in the associated project, those create operations fail.

Existing resources

Existing resources are not subject to newly created organization policies. For example, if you create an organization policy that requires you to specify a CMEK for every create operation, the policy does not retroactively apply to existing instances and backup chains. Those resources are still accessible without a CMEK. If you want to apply the policy to existing resources, whether instances or backup chains, you must replace them.

Required permissions to set an organization policy

The permission to set or update the organization policy might be difficult to acquire for testing purposes. You must be granted the Organization Policy Administrator role, which can only be granted at the organization level.

Although the role must be granted at the organization level, it is still possible to specify a policy that only applies to a specific project or folder.

Impact of Cloud KMS key rotation

Filestore doesn't automatically rotate a resource's encryption key when the Cloud KMS key associated with that resource is rotated.

  • All data in existing instances and backups continues to be protected by the key version with which they were created.

  • Any newly-created instances or backups use the primary key version specified at the time of their creation.

When you rotate a key, data that was encrypted with previous key versions isn't automatically re-encrypted. To encrypt your data with the latest key version, you must decrypt the old key version from the resource, and then re-encrypt the same resource with the new key version. In addition, rotating a key does not automatically disable or destroy any existing key versions.

For detailed instructions on how to perform each of these tasks, see the following guides:

Filestore access to the Cloud KMS key

A Cloud KMS key is considered available and accessible by Filestore under the following conditions:

  • The key is enabled
  • The Filestore service account has encrypt and decrypt permissions on the key

What's next