Prepare and test your skills
Prepare and test your skills
Envelope encryption and secrets storage architecture is the design that protects CI/CD secrets, configuration, and build artifacts with layered keys controlled in Cloud Key Management Service (Cloud KMS) (opens in a new tab). In this architecture, a per-object data encryption key (DEK) encrypts the payload with AES-256, and a customer-managed key encryption key (KEK) wraps that DEK. The wrapped DEK travels and is stored alongside the encrypted payload in Secret Manager, Cloud Storage, or another CMEK-integrated service, so reading the payload requires both resource permission and permission to unwrap the DEK with the KEK.
Envelope encryption with Customer-Managed Encryption Keys (CMEK) (opens in a new tab) separates the key that encrypts data from the key that encrypts other keys. The flow starts when a CMEK-integrated service generates or obtains a DEK, uses the DEK to encrypt the secret value, artifact, or object, then sends the DEK to Cloud KMS where the CMEK as KEK encrypts the DEK. For decryption, the service sends the wrapped DEK back to Cloud KMS, Cloud KMS decrypts the DEK with the CMEK, and the service uses the unwrapped DEK in memory to decrypt the payload. Raw CMEK material never leaves Cloud KMS, while DEKs can be unique per object.
All CMEK keys for envelope encryption use the symmetric ENCRYPT_DECRYPT purpose with the GOOGLE_SYMMETRIC_ENCRYPTION algorithm, and each key supports unlimited key versions. The primary key version encrypts new DEKs, while older enabled versions remain available to decrypt previously wrapped DEKs. If the CMEK is disabled, destroyed, or its roles/cloudkms.cryptoKeyEncrypterDecrypter grant to the service agent is revoked, decrypt operations fail and protected secrets, buckets, and build outputs become unreadable.
The choice between Google-managed encryption and CMEK determines ownership, visibility, and control over the KEK layer:
| Key type | Ownership and sharing | Rotation and lifecycle control | Audit and policy control |
|---|---|---|---|
| Google-owned and Google-managed key | Owned by Google; data from multiple customers can share the same KEK; metadata not visible | Rotated automatically by Google; no customer control | No key usage logs or CMEK organization policies |
| Cloud KMS manual CMEK | Owned by customer; unique to a customer; metadata visible | Customer sets rotation schedule, enables, disables, destroys, and manages versions | Admin Activity and optional Data Access audit logs plus CMEK organization policies |
| Cloud KMS Autokey | Owned by customer; unique to a customer; metadata visible | Same customer control as manual, with automated provisioning and yearly rotation defaults | Same logging and policy support as manual CMEK |
Secret Manager payload protection with CMEK applies envelope encryption (opens in a new tab) to secret values at rest while preserving transparent access for authorized pipelines. After CMEK is configured, a build step or workload that has Secret Manager access does not need direct access to the KEK; the Secret Manager service agent uses its CryptoKey Encrypter/Decrypter grant to unwrap the DEK and return the plaintext secret. This trust boundary separates secret consumers in the application or pipeline project from key administrators in the key project, which enforces separation of duties.
Replication and location determine where wrapped secrets and KEK operations can occur. Automatic replication is recommended for most workloads because it meets availability and performance needs without pinning secret replicas to specific locations. When a workload has strict residency requirements, a user-managed replication policy selects explicit replica locations through the API, and the Cloud KMS key ring must reside in a location compatible with those replicas. The KEK should be created in the same location family as the resources it protects to keep encrypt and decrypt calls local and policy-compliant.
Cloud Storage bucket protection with CMEK applies envelope encryption to objects that commonly hold CI/CD build artifacts, container image layers, test evidence, and deployment bundles. When an object is written, Cloud Storage generates a DEK for the object, wraps that DEK with the designated Cloud Storage CMEK, and stores the wrapped DEK with the object metadata. On read, Cloud Storage calls Cloud KMS to unwrap the DEK and then decrypts the object, so pipeline service accounts need object access while only the Cloud Storage service agent needs the KEK permission.
Location alignment is strict for buckets and keys. A key ring used for a bucket must be created in the same location scope as the bucket, such as the US multi-region for a bucket spanning us-east1 and us-west1, or the same predefined dual-region for asia1, eur4, and nam4 buckets. Objects encrypted with CMEKs do not return CRC32C checksums or MD5 hashes on JSON API listings, so inventory tooling that performs per-object GET requests for checksums will list substantially slower. If the bucket CMEK is disabled or its service-agent grant is revoked, new builds cannot write readable artifacts and existing artifacts cannot be pulled, and some dependent services can suffer permanent data loss if the key stays inaccessible too long.
Key provisioning for CI/CD pipelines follows either manual creation or Cloud KMS Autokey (opens in a new tab), and both produce standard Cloud Hardware Security Module (HSM) keys that behave identically in CMEK-integrated services. Autokey generates key rings, AES-256 GCM keys, and service-agent grants on demand as developers create resources, with multi-tenant HSM protection, yearly rotation, same-location placement as the protected resource, and per-resource-type specificity. Manual provisioning requires advance planning of key rings, keys, locations, and Identity and Access Management (IAM) grants, but allows full control over naming, granularity, and protection level. Autokey also removes the need to run infrastructure-as-code pipelines with elevated key-creation privileges, because the Cloud KMS service agent provisions keys under delegated authority.
Manual CMEK setup for a pipeline resource follows an ordered dependency chain where each step depends on the prior step:
roles/cloudkms.cryptoKeyEncrypterDecrypter on that CMEK to the service agent of Secret Manager, Cloud Storage, Cloud Run, or the relevant build service.Governance and storage models determine who manages keys and where keys live relative to pipeline resources. Centralized governance places lifecycle responsibility with a dedicated security or platform team and suits regulated environments, while delegated governance lets application owners manage keys within guardrails such as organization policies, IAM allow policies, and IAM deny policies. Dedicated-project storage places keys for multiple applications in a centralized key project per environment, separate from the projects holding the protected resources, while same-project storage places the key in the same project as the data it protects. Use one centralized key project per environment and do not co-locate Cloud KMS resources with the resources they protect when separation of duties is required.
Protection level and key material choices trade cost, control, and operational overhead, as described in recommended practices (opens in a new tab):
Prefer Google-generated key material because it never exposes raw material outside Cloud KMS and supports automatic rotation; imported bring-your-own-key material requires external generation, secure escrow, leak-resistant import automation, and planning for failed rotations or re-import of destroyed versions.
Rotation and destruction guardrails keep pipeline encryption recoverable and compliant without blocking releases. Enable automatic rotation with a period that meets policy needs, ideally at least once per year and more frequently for sensitive workloads. A key version pending destruction enters a scheduled for destruction state where cryptographic operations fail, followed by irrecoverable destruction after the soft-delete period; the default soft-delete period is 30 days, the minimum configurable duration is 24 hours, and the duration can only be set at creation. Enforce constraints/cloudkms.minimumDestroyScheduledDuration with at least 30 days, enforce constraints/cloudkms.allowedProtectionLevels to limit new keys and versions to approved HSM or external levels, and enforce constraints/gcp.restrictNonCmekServices to require CMEK for services such as Cloud Storage, BigQuery, and Vertex AI.
Detective controls track which pipeline resources depend on which keys and whether keys follow policy. Aggregate Admin Activity audit logs centrally for all Cloud KMS create, modify, enable, disable, and destroy actions, and enable Data Access logs for encrypt and decrypt calls only with a clear use case because CMEK data-access volume can substantially increase cost. Use the Cloud KMS inventory API and key-usage dashboard to map keys to protected secrets, buckets, and build resources and to identify data made inaccessible by disabled or destroyed versions, use Cloud Monitoring alerts for sensitive operations such as scheduling destruction, and enable Security Command Center to surface findings such as publicly accessible keys, overly permissive owner roles, or separation-of-duties violations.
Exam tip: Revoking the service agent's Encrypter/Decrypter role and disabling or destroying the CMEK both make data inaccessible, but only destruction after the scheduled-for-destruction window is irrecoverable; restore the key before that window expires if audit logs show it is still in use.
Cryptographic key lifecycle and pipeline automation in Google Cloud is the end-to-end management of encryption keys from creation through rotation to destruction while keeping continuous integration and continuous deployment (CI/CD) pipelines continuously decryptable. Cloud Key Management Service (Cloud KMS) (opens in a new tab) is the centralized service that creates, imports, stores, and uses cryptographic keys, and it integrates with other services through customer-managed encryption keys that act as key-encryption keys in envelope encryption. Pipeline automation means deployment jobs and infrastructure-as-code request encryption, decryption, and signing from Cloud KMS through Identity and Access Management (IAM) permissions and service agents, so rotation or revocation must be coordinated to avoid failed decrypts during releases.
Key ownership in Google Cloud determines who controls creation, rotation, access, and destruction and whether logical separation exists between customers. Customer-managed encryption keys (CMEKs) are keys the customer owns, either provisioned manually or provisioned on demand by Cloud KMS Autokey, while Google-owned and Google-managed keys are owned by Google with no customer visibility, control, or audit logging. Only customer-owned keys provide unique keys per customer, control of rotation, organization policy enforcement, and administrative and data-access audit logs.
Cloud KMS organizes resources as key ring, key, and key version, where the key ring is bound to a location, the key defines purpose and policy, and each key version holds distinct key material. Because Cloud KMS uses envelope encryption (opens in a new tab), the CMEK functions as a key-encryption key (KEK) that encrypts data-encryption keys (DEKs), and the protected service stores only the wrapped DEK alongside the data. A request therefore flows from the workload or service agent to the Cloud KMS API, which unwraps the DEK with the active or prior key version and returns data access without exposing raw KEK material to the pipeline.
| Key type | Ownership | Customer control and visibility |
|---|---|---|
| Cloud KMS Autokey | Customer | Automated creation and assignment by service agent; customer retains manual control, rotation control, audit logging, and regulatory support |
| Customer-managed manual key | Customer | Fully manual creation, rotation, enable, disable, and destroy; unique per customer with audit logging and policy controls |
| Google-owned and Google-managed default key | No customer view, management, rotation control, or logging; multiple customers may share the same KEK |
Symmetric and asymmetric keys in Cloud KMS serve different pipeline functions, and only symmetric keys can protect stored pipeline data through CMEK integrations. Cloud KMS directly supports symmetric and asymmetric keys for encryption, decryption, signing, and signature validation through the REST API, gRPC, client libraries, and PKCS #11 integration, with behavior varying by protection level. All CMEK keys must use the symmetric ENCRYPT_DECRYPT purpose with the GOOGLE_SYMMETRIC_ENCRYPTION algorithm, which is an AES-256 key used as a KEK for compatible storage and compute services.
Pipeline secrets, build artifacts, container images, Terraform state, and configuration values that rest in Cloud Storage, BigQuery, Compute Engine, or Spanner therefore depend on symmetric CMEKs, while asymmetric keys are used when the pipeline must sign releases or validate signatures outside a CMEK integration. Choosing symmetric CMEKs isolates pipeline secrets behind a customer-owned cryptographic boundary that supports crypto-shredding by destroying the key, whereas choosing asymmetric keys supports authenticity without providing at-rest CMEK protection. A pipeline that both encrypts secrets and verifies provenance will use a symmetric CMEK for storage encryption and a separate asymmetric key for signing.
Key creation in Cloud KMS binds the key to a project, location, protection level, purpose, and initial primary version that will perform new encryptions. The key ring must be created in the same location as the resource it protects, and Cloud KMS creates, stores, and processes key material only in that selected location to satisfy regionality. Best practice places key rings in a dedicated key project per environment rather than in the same project as the data, with one centralized key project per environment and separate key rings for each location where protected resources exist.
Protection level defines where key material lives and how cryptographic operations are performed, as described in best practices for using CMEKs (opens in a new tab):
Key material should be generated inside Cloud KMS whenever possible because Cloud KMS never exposes raw material externally and can automatically generate new versions on the configured rotation schedule. Imported bring-your-own-key material requires external generation, secure escrow, leak-resistant import procedures, automation that consistently imports new versions on schedule, and handling for the risk that retained external material could re-import a previously destroyed key.
Key rotation in Cloud KMS creates a new primary key version that encrypts new data while prior enabled versions remain available to decrypt existing data, which is what allows pipelines to continue running. Automatic rotation should be enabled with a period that meets policy needs, ideally no less than once per year, with more frequent rotation for sensitive workloads; keys created by Autokey are AES-256 GCM HSM keys rotated yearly. The pipeline depends on both the primary version for new encrypt operations and the older versions for decrypt operations, so disabling or destroying an older version before data is re-encrypted causes decrypt failures in builds, deploys, and secret retrieval.
Rotation behavior differs by integrated service, so pipeline owners must verify re-encryption semantics before assuming rotation is transparent, as noted in recommended practices (opens in a new tab):
Exam tip: Rotation never automatically re-encrypts all existing data; Spanner re-encrypts the DEK, Cloud Storage applies the new version only to new objects, and BigQuery keeps existing tables on the old version unless recreated.
The destruction lifecycle in Cloud KMS moves a key version through ordered states that control whether pipelines can still use it. A version starts enabled for both encrypt and decrypt, can transition to disabled to temporarily block all cryptographic use without deleting material, then to scheduled for destruction during a soft-delete window, and finally to destroyed where material is irrecoverably deleted unless the key was importable and retained externally. While a key is scheduled for destruction, Cloud KMS rejects all encrypt, decrypt, and sign requests with that version, so any pipeline that still references it fails until the key is restored or data is re-encrypted.
The scheduled for destruction duration can only be set during key creation, defaults to a 30-day soft-delete period that allows restoration after accidental scheduling, but can be set as low as 24 hours by a holder of the Cloud KMS Admin role. Operational guardrails prevent unsafe destruction and privilege drift across pipelines and projects. Enforce constraints/cloudkms.minimumDestroyScheduledDuration with a minimum of 30 days, enforce constraints/cloudkms.allowedProtectionLevels to limit new keys and import jobs to approved backends, enforce constraints/gcp.restrictNonCmekServices to require CMEK where needed, and place project liens on key projects to block accidental project deletion.
Automating keys in deployment pipelines means provisioning, assigning, and granting access to keys without giving build identities standing key-administration power. Cloud KMS Autokey delegates provisioning authority to the Cloud KMS service agent in the project, so when a developer creates a supported resource the service agent provisions the correct key ring, key, and service-account grant on demand following location alignment, per-resource-type specificity, HSM protection, yearly rotation, and separation of duties. Keys requested through Autokey work identically to other Cloud HSM keys with the same settings and support regulatory requirements for customer-managed keys, including use described for Google Security Operations (opens in a new tab).
Manual provisioning requires a key administrator to pre-create rings, keys, and grants and coordinate with developers before deployment, which creates bottlenecks and tempts teams to run infrastructure-as-code with elevated key-creation privileges. Autokey simplifies Terraform and other infrastructure-as-code flows because the pipeline identity no longer needs permission to create keys, only permission to request protected resources while the service agent performs key creation and IAM binding. Dedicated-project storage with one key project per environment folder centralizes audit and rotation for regulated estates, while same-project storage where the key follows the data delegates lifecycle to application owners under central guardrails; either model can use Autokey, but the architecture should stay consistent across environments.
Governance in Cloud KMS defines who manages key lifecycles and guardrails, ranging from centralized governance where a security or platform team owns all keys to delegated governance where a central team sets organization policies and IAM deny policies and application owners operate keys in their projects. Centralized governance suits strict regulatory or external-key-system requirements, while delegated governance removes central bottlenecks but depends on enforced constraints and least privilege. Separation of duties requires that identities that use keys for encrypt and decrypt differ from identities that manage rotation, destruction, and state changes, enforced with the most limited predefined IAM roles and without basic roles such as owner on key projects.
Detective controls let pipeline and security teams verify that keys remain available and compliant before and after rotation events. Aggregate Admin Activity audit logs centrally to review all key creation, rotation, disable, and destroy-scheduling actions, and enable Data Access logs for encrypt and decrypt use only with a defined use case because CMEK data-access volume increases cost. Use the Cloud KMS inventory API and encryption-metrics and key-usage dashboards to map which pipeline artifacts and resources depend on each key version and to identify data made inaccessible by a disabled or destroyed version, use Cloud Monitoring alerts on events such as scheduling destruction to trigger triage and restore, and enable Security Command Center to surface publicly accessible keys, overly permissive owner grants, and separation-of-duties violations.
Least Privilege IAM and Workload Identity Security is the practice of granting only the minimum Identity and Access Management (IAM) permissions on Cloud Key Management Service (Cloud KMS) (opens in a new tab) resources needed for pipelines to run. Cloud Key Management Service (Cloud KMS) is fully integrated with IAM and Cloud Audit Logs, so permissions can be managed on individual keys and every administrative use can be audited. For continuous integration and continuous deployment (CI/CD), this means deployment service accounts, pipeline runners, and external identities get key-use access only where needed, while key administration stays in a separate trust boundary.
Granular IAM on KeyRing and CryptoKey resources is the ability to set different permissions at the ring level and on each individual key. A KeyRing is a container that groups CryptoKeys in a single location, and a CryptoKey is the named key object whose versions perform encrypt and decrypt operations. Because Cloud KMS evaluates IAM at both levels, a pipeline identity can be granted encrypt and decrypt rights on one CryptoKey without gaining rights to every key in the ring or project. Management of keys includes creation, choice of protection level, assignment of management authority, control of access and usage, rotation control, status changes, and destruction or deletion of versions, rings, and keys.
Apply the principle of least privilege by granting the most limited predefined roles that let each principal complete its task. Do not use basic roles such as Owner, because they grant broad access across the project and break separation of duties. In the key project, the user who creates rings and keys needs cloudkms.keyRings.getIamPolicy and cloudkms.keyRings.setIamPolicy, which are included in the predefined roles/cloudkms.admin role. The service account that encrypts pipeline secrets or disks then receives only key-use permission on the specific CryptoKey it must use.
Separation of duties in Cloud KMS is the enforcement that identities that manage keys are different from identities that use keys to encrypt and decrypt. Key administrators handle lifecycle operations such as creating, enabling, disabling, rotating, and destroying key versions and controlling IAM on keys. Key users, including deployment service accounts and CI/CD runners, only call encrypt and decrypt through the CryptoKey. Cloud KMS provides several predefined IAM roles with specific privileges and limitations to implement this split for users and service accounts.
Maintain this split even when automation creates keys on demand. With Cloud KMS Autokey, the Cloud KMS administrator delegates authority to the Cloud KMS service agent in the project, and a developer request causes the service agent to provision the correct key for that intent. Autokey provisioning follows separation of duties by design, so identities that can use the key are different from identities that manage rotation, destruction, or state changes. Autokey also simplifies Terraform and other infrastructure-as-code usage because it removes the need to run pipelines with elevated key-creation privileges.
Exam tip: Never combine key administration and key use in one identity and never use basic roles — Security Command Center flags Cloud KMS projects with the Owner role and IAM grants that violate separation of duties.
Project isolation is the use of a dedicated key project to create an IAM and administrative boundary between keys and the data the keys protect. Use one centralized key project for each environment and do not create Cloud KMS resources in the same project as the Google Cloud resources the keys protect. If keys must live with the data, remove the Owner role from that project to preserve separation between key administrators and data administrators. Within a project, create Cloud KMS resources in a supported location and create KeyRings for each location where protected resources exist, so keys are created, stored, and processed only in the selected location.
The choice of storage model determines where that boundary sits:
| Storage model | Where keys live | Boundary effect |
|---|---|---|
| Dedicated-project key storage | A dedicated key project holds keys for multiple applications, usually one key project per environment folder | Key administrators and pipeline identities operate in different projects; Autokey is supported |
| Same-project key storage | Keys live in the same project as the resources they protect, so the key follows the data | Data and key administration share a project boundary and require stricter IAM separation; Autokey is supported |
Centralized governance fits dedicated-project storage when a security or platform team must manage all key lifecycles for compliance. Delegated governance lets a central team enforce guardrails with organization policies, IAM grants, and deny policies while application owners manage keys in their own projects.
Secure pipeline access means every CI/CD runner authenticates as a distinct service account and receives key-use rights only on the CryptoKeys for its environment. The request flow depends on the service agent model, where a Google-managed service agent performs encryption on behalf of the pipeline. When a compatible service uses customer-managed encryption keys (CMEKs) as described in the encryption and key management deep dive (opens in a new tab), encrypt and decrypt operations are handled transparently by the resource service agent without end-user effort. Because the service agent accesses the CryptoKey, the pipeline identity itself does not need administrative rights on the KeyRing.
Autokey establishes this access automatically in the correct order:
For pipelines that run outside Google Cloud or in another project, apply the same boundary by granting the federated or external service account only key-use rights on the target CryptoKey. Keep key-creation, rotation, and destruction rights in the key project with the security team. Use project liens on key projects to prevent accidental deletion that would make pipeline secrets or encrypted disks inaccessible.
Guardrails and detective controls ensure least-privilege grants stay correct over time. Preventive guardrails include organization policy constraints such as constraints/gcp.restrictNonCmekServices to require CMEKs, constraints/cloudkms.allowedProtectionLevels to enforce allowed protection levels, and constraints/cloudkms.minimumDestroyScheduledDuration to require a minimum scheduled-for-destruction duration. Detective controls aggregate administrative activity audit logs for all resources in the organization and optionally log data access operations that use keys, including encrypt and decrypt calls, following best practices for using CMEKs (opens in a new tab) and recommended practices (opens in a new tab).
Enable audit logging with cost and coverage tradeoffs in mind:
DATA_READ for the Cloud KMS API track credential issuance and key usage, but enabling them for CMEK workloads can generate substantial volume because every service operation creates logs.ENCRYPT_DECRYPT with GOOGLE_SYMMETRIC_ENCRYPTION.Envelope encryption uses a per-object data encryption key (DEK) to encrypt the payload with AES-256 and a customer-managed key encryption key (KEK) in Cloud KMS to wrap that DEK, with the wrapped DEK stored alongside the encrypted payload in Secret Manager, Cloud Storage, or another CMEK-integrated service. For decryption the service sends the wrapped DEK to Cloud KMS for unwrapping and then uses the unwrapped DEK in memory, while raw CMEK material never leaves Cloud KMS. All CMEK keys use the symmetric ENCRYPT_DECRYPT purpose with the GOOGLE_SYMMETRIC_ENCRYPTION algorithm.
Google-owned and Google-managed keys are owned by Google, can be shared across customers, rotate automatically, and provide no customer visibility, key usage logs, or CMEK organization policies. Manual CMEK and Autokey are both customer-owned and unique per customer with visible metadata, customer-controlled rotation and lifecycle, and Admin Activity plus optional Data Access logs and CMEK organization policies, with Autokey differing by provisioning key rings, AES-256 GCM keys, and service-agent grants on demand with yearly rotation defaults.
If the CMEK is disabled, destroyed, or its roles/cloudkms.cryptoKeyEncrypterDecrypter grant to the service agent is revoked, decrypt operations fail and protected secrets, buckets, and build outputs become unreadable. A disabled key or revoked grant blocks access until restored, while destruction is irrecoverable after the scheduled-for-destruction window, which defaults to a 30-day soft-delete period and can be set as low as 24 hours only at creation.
Your organization uses an external CI/CD pipeline running in an external cloud provider to deploy application infrastructure. The pipeline needs to decrypt sensitive deployment configuration files using a Cloud KMS key before initiating rollout.
To meet strict security compliance, your implementation must satisfy the following requirements:
Which configuration should you implement?
Create a service account with roles/cloudkms.admin on the target CryptoKey, assign the pipeline runner roles/iam.workloadIdentityPoolAdmin on the project, and export audit logs to BigQuery.
Configure a Workload Identity Pool mapping stable external claims, grant the federated identity roles/iam.workloadIdentityUser on a dedicated service account, grant that service account roles/cloudkms.cryptoKeyDecrypter specifically on the target CryptoKey, and enable Data Access audit logs for the Security Token Service and IAM APIs.
Configure a Workload Identity Pool mapping external usernames, grant the federated principal roles/cloudkms.cryptoKeyEncrypterDecrypter on the parent KeyRing, and enable default Cloud Logging for Cloud KMS.
Generate a downloadable JSON service account key for a deployment service account, assign it roles/cloudkms.cryptoKeyDecrypter at the project level, and enable Security Command Center audit alerting.
Last updated