Skip to main content

More Info:

Enable application-layer secrets encryption so Kubernetes Secrets are encrypted at rest using a Cloud KMS key you control. This protects secret data beyond Googles default encryption.

Risk Level

High

Address

Security

Compliance Standards

  • CIS GKE

Triage and Remediation

Remediation

Manual Steps

  1. Identify the GKE cluster(s) and current encryption status
    Run on any machine with gcloud configured:
    Review whether state is "ENCRYPTED" and a keyName is present. If state is "DECRYPTED" or keyName is empty, application‑layer secrets encryption with Cloud KMS is not enabled.
  2. Decide the KMS project, location, and key structure
    With your security/ops team, determine:
    • Which project will own the KMS key (<key_project_id>).
    • Region (<location>) that matches or is appropriate for your cluster.
    • Key ring name (<ring_name>) and key name (<key_name>).
      Document whether you will use a dedicated key per cluster, per environment, or shared across clusters, considering key‑rotation and access‑control policies.
  3. Create or verify the Cloud KMS key
    If a suitable key does not already exist, create one (run on any machine with gcloud):
    If using an existing key, confirm it is of purpose ENCRYPT_DECRYPT and in the correct region:
  4. Grant the GKE service agent access to the KMS key
    First, identify the Kubernetes Engine Service Agent for the cluster project (run on any machine with gcloud):
    Then grant it roles/cloudkms.cryptoKeyEncrypterDecrypter on the key:
    Replace <service_account_name> with the email printed by the previous command.
  5. Enable application‑layer secrets encryption on the cluster
    For a new cluster (decide whether to recreate vs update an existing cluster):
    To enable on an existing cluster:
    Assess operational impact: cluster control‑plane reconfiguration may temporarily affect control‑plane availability; coordinate during a maintenance window if needed.
  6. Verify encryption is enabled and using the intended key
    After the update/recreate completes, run (any machine with gcloud):
    Confirm that state is "ENCRYPTED" and that keyName matches
    projects/<key_project_id>/locations/<location>/keyRings/<ring_name>/cryptoKeys/<key_name>.
kubectl cannot configure application-layer secrets encryption or Cloud KMS keys, because this setting is managed entirely in the GKE control plane via the Google Cloud Console, gcloud CLI, or IaC. To remediate this finding, follow the guidance in the Manual Steps section for making the change at the cloud provider configuration level.
What indicates a problem in the script output
  • Any row with STATE=NOT_ENCRYPTED:
    • The databaseEncryption block is missing, or
    • .databaseEncryption.state is not ENCRYPTED.
    • This means Kubernetes Secrets are not protected with Cloud KMS as required.
  • Any row with STATE=MISCONFIGURED:
    • state is ENCRYPTED but keyName is missing, or the cluster could not be described.
    • Requires manual review to ensure a valid Cloud KMS key is configured.
  • Only rows with STATE=OK meet the requirement for CIS GKE 5.3.1.