Skip to main content

More Info:

Advisory: EncryptionConfiguration with a KMS provider should be enabled for Secret resources so etcd does not store secrets in plaintext.

Risk Level

High

Address

Security

Compliance Standards

  • Cloudanix Best Practice

Triage and Remediation

Remediation

Manual Steps

  1. Identify the cluster(s) to review
    • On any machine with gcloud installed, set the project and list clusters:
    • Note each cluster’s NAME, LOCATION, and whether it is Autopilot or Standard.
  2. Check if secrets encryption is already enabled for each cluster
    • For each cluster, run:
    • Review the output:
      • state: ENABLED and a non-empty keyName means KMS envelope encryption is enabled.
      • state: DECRYPTED or missing databaseEncryption means this control is not satisfied.
  3. Review the KMS key configuration and status (if enabled)
    • From the databaseEncryption.keyName output, identify the KMS key:
      projects/PROJECT_ID/locations/LOCATION/keyRings/RING/cryptoKeys/KEY
    • Verify the key exists and is enabled:
    • Confirm an appropriate rotation policy and IAM permissions for GKE’s service account.
  4. Decide on enabling encryption for clusters where it is not enabled
    • Understand impact: this is a control-plane configuration change; enabling database encryption on an existing GKE cluster is supported but may be irreversible and can have performance implications.
    • Decide per cluster whether to:
      • Leave it as-is (with documented risk acceptance), or
      • Enable KMS database encryption using either a new or existing CMEK key that meets your org’s key-management and IAM policies.
  5. Enable database (secrets) encryption for a cluster (if required)
    • Ensure you have or create a CMEK key:
    • Enable encryption on the target cluster (Standard or Autopilot):
    • Follow any prompts; note this may take several minutes and affects how data (including Secrets) is stored in etcd.
  6. Verify and document the final state
    • Re-run the describe command to confirm encryption is now enabled and points to the intended key:
    • Record for each cluster: state, keyName, KMS key rotation policy, and the date of the change or the explicit decision to accept the risk if encryption remains disabled.
kubectl cannot enable or configure envelope/KMS encryption for Secrets in GKE; this setting is part of the GKE cluster’s control-plane configuration managed via the Google Cloud Console, gcloud CLI, or IaC. To address this finding, make the change at the cloud provider level as described in the Manual Steps section.
What output indicates a problem
  • For any cluster where the script prints:
    • STATUS: FINDING (Secrets NOT using KMS envelope encryption)
      or
    • databaseEncryption.state: DECRYPTED, UNSPECIFIED, or missing,
that cluster does not have GKE Secret KMS encryption at rest configured and should be treated as non-compliant with “Secrets Should Be Encrypted At Rest” until reviewed and remediated.