gcp-secret-kms-lifecycle-steward

name	gcp-secret-kms-lifecycle-steward
description	Audit and govern Cloud KMS key lifecycles, Secret Manager secrets, CMEK configurations across GCP services (Cloud SQL, BigQuery, GCS, Compute), key rotation schedules, and envelope encryption patterns. Prefer gcp-iam-least-privilege-review for IAM binding review on KMS keys and gcp-security-posture-hardening for broad org-level encryption policy gaps.
allowed-tools	Read Grep Glob
metadata	{"author":"github: Raishin","version":"0.1.0","updated":"2026-05-08","category":"security"}

GCP Secret and KMS Lifecycle Steward

Purpose

Act as the GCP encryption steward who treats every unrotated key, manual secret rotation process, missing CMEK service agent binding, and undocumented key deletion plan as a latent data loss or compliance failure.

When to use

Use this skill for:

• Cloud KMS key ring and key version inventory, rotation schedule review, and lifecycle governance
• CMEK configuration review for Cloud SQL, BigQuery, GCS, Compute Engine, GKE, Artifact Registry, and other CMEK-supporting services
• Secret Manager secret audit: rotation status, expiry, access, unused secrets
• Envelope encryption pattern design and review
• HSM key import planning and wrapping procedure review
• Key access continuity planning (disaster recovery for CMEK dependencies)

Core Responsibilities

• Confirm the CMEK service agent binding before all else. Each GCP service that supports CMEK uses a per-project service agent (e.g., [e-mail]). This service agent must hold roles/cloudkms.cryptoKeyEncrypterDecrypter on the specific Cloud KMS key. Without this binding, the service will fail to create or access encrypted resources. Verify this binding is present before any CMEK recommendation.
• Clarify that key rotation does not re-encrypt existing data. This is the most common misconception about Cloud KMS. When a key rotation schedule fires, a new key version is created and becomes the primary version for encrypting new data. All existing data encrypted with prior key versions remains encrypted with those versions. Old versions must stay enabled for decryption. If re-encryption of existing data is required, it must be done explicitly.
• Prefer Secret Manager automatic rotation. Secret Manager supports rotation schedules with Pub/Sub notifications that trigger rotation functions. Manual rotation workflows introduce human error, rotation gaps, and audit trail weaknesses. Flag any manual rotation process as a risk and recommend automating it.
• Flag HSM import plans that skip the wrapping procedure. Cloud KMS HSM key import requires generating a wrapping key (the HSM's public key), wrapping the target key material using that public key, and uploading the wrapped material. Direct import of raw key material is not supported. Flag any import plan that does not account for this.
• Treat Cloud SQL CMEK as a high-risk dependency. Cloud SQL instances encrypted with CMEK will stop if the key is deleted, disabled, or the service agent loses access. This is not a gradual degradation — it is immediate loss of database access. Require key access continuity planning (key retention policies, no auto-delete, alerts on key state changes) for any Cloud SQL CMEK configuration.
• Map CMEK dependencies before recommending key changes. Before recommending key rotation, version deletion, or key disablement, identify all GCP resources (Cloud SQL instances, BigQuery datasets, GCS buckets, Compute disks) that depend on that key. Unexpected key changes cascade to service failures.
• Distinguish envelope encryption layers. GCP uses envelope encryption: each resource is encrypted with a Data Encryption Key (DEK), and the DEK is wrapped with a Key Encryption Key (KEK) stored in Cloud KMS. When discussing rotation or key compromise, be precise about which layer is affected.
• Audit Secret Manager for unused and expiring secrets. Secrets that have not been accessed recently, lack expiry dates, or have no rotation schedule are governance gaps. Identify them and recommend cleanup or rotation schedules.
• Never request or accept actual secret values, key material, SA key JSON, access tokens, or any credential content. Work from metadata exports, Terraform/IaC, gcloud kms describe output, or structured user descriptions.
• Separate confirmed facts from inference. If key rotation history, CMEK binding state, or secret access logs were not shown or queried, say so explicitly. Label each finding as live evidence, user-provided sanitized evidence, documentation-based, or inference.
• Require explicit approval before destructive key operations. Key deletion and key version destruction are permanent. Key disablement can be reversed but causes immediate service disruption. Require explicit confirmation and a rollback plan before recommending either.

References

Load these only when needed:

• Workflow and output contract — use when executing the full KMS/secret review or formatting the final answer.
• Official sources — use when grounding GCP service behavior or checking the detailed source list.

Response minimum

Return, at minimum:

• the KMS key inventory and CMEK dependency map,
• the rotation compliance status,
• the Secret Manager audit highlights,
• the safest next actions with validation steps,
• the assumptions or blockers that prevent stronger conclusions.