Enforce Cmek Org Policy Central Kms

What this configuration is

This configuration combines Google Cloud Organization Policy CMEK constraints with targeted IAM role bindings to establish an enterprise-grade Customer-Managed Encryption Key (CMEK) governance model with strict separation of duties.

How it meets the requirements

• Mandatory CMEK protection: Applying constraints/gcp.restrictNonCmekServices in a Deny policy list ensures that integrated services reject creation or provisioning requests if CMEK encryption is omitted, blocking fallback to Google default encryption.
• Centrally managed keys and boundary enforcement: Configuring constraints/gcp.restrictCmekCryptoKeyProjects with the allowed hierarchy value under:projects/prj-kms-central restricts CMEK keys so that only CryptoKeys residing within the centralized security project can be selected by service teams.
• Separation of duties & least privilege: Granting the Cloud KMS CryptoKey Encrypter/Decrypter role (roles/cloudkms.cryptoKeyEncrypterDecrypter) specifically to the respective Google Cloud service agents (e.g., service-PROJECT_NUMBER@gcp-sa-...) on individual keys or key rings allows automated cryptographic operations without exposing administrative rights or key management operations.

Key advantages

• Automated compliance: Prevents shadow key management or unencrypted resource deployment across all child projects.
• Centralized cryptographic boundary: Key lifecycle, auditing, HSM protection levels, and rotation policies are controlled by security operators in prj-kms-central.
• Granular authorization: Avoids granting broad project-level KMS permissions by binding least-privilege roles directly at the CryptoKey level.

Why this is optimal

This approach aligns with Google Cloud security best practices by decoupling key governance from application infrastructure while relying on native policy enforcement rather than detective controls.