Detections
Analytics

5.3.1 Enable application-layer Secrets encryption with Cloud KMS keys

Information

Enable application layer Secrets encryption for GKE Autopilot clusters using a Cloud KMS key. This control adds customer managed encryption for Kubernetes Secret resources stored in the cluster state database, providing an additional protection layer beyond Google managed encryption at rest.

By default, GKE encrypts customer content at rest, including Kubernetes Secrets, using encryption that Google manages automatically. Application layer Secrets encryption adds another layer by encrypting Secret data before it is written to the cluster state database, using a key that is managed in Cloud KMS.

This improves protection for sensitive Kubernetes Secret data by allowing the organization to manage the encryption key lifecycle, including key access control, rotation, and disablement. It is important for clusters that store sensitive application credentials, tokens, certificates, or other Secret values that require stronger key management controls.

Solution

Enable application layer encryption on the GKE Autopilot cluster when the audit shows that databaseEncryption.state is not ALL_OBJECTS_ENCRYPTION_ENABLED or ENCRYPTED, databaseEncryption.currentState is not CURRENT_STATE_ALL_OBJECTS_ENCRYPTION_ENABLED or CURRENT_STATE_ENCRYPTED, or databaseEncryption.keyName does not reference the approved Cloud KMS CryptoKey. Before enabling encryption, grant the Kubernetes Engine Service Agent permission to use the Cloud KMS key. The service agent needs the Cloud KMS CryptoKey Encrypter/Decrypter role so GKE can encrypt and decrypt Kubernetes Secret data in the cluster state database.

Define the approved Cloud KMS key resource:

KMS_KEY=projects/$KMS_PROJECT_ID/locations/$KMS_LOCATION/keyRings/$KMS_KEYRING/cryptoKeys/$KMS_KEY_NAME

Grant the Kubernetes Engine Service Agent access to use the key:

gcloud kms keys add-iam-policy-binding $KMS_KEY \\
 --member serviceAccount:service-$PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \\
 --role roles/cloudkms.cryptoKeyEncrypterDecrypter

Enable application layer Secrets encryption on the GKE Autopilot cluster:

gcloud container clusters update $CLUSTER_NAME \\
 --location $LOCATION \\
 --project $PROJECT_ID \\
 --database-encryption-key $KMS_KEY

After the update completes, rerun the audit command:

gcloud container clusters describe $CLUSTER_NAME \\
 --location=$LOCATION \\
 --project=$PROJECT_ID \\
 --format='json(databaseEncryption)'

Expected values:

{
 "databaseEncryption": {
 "currentState": "CURRENT_STATE_ALL_OBJECTS_ENCRYPTION_ENABLED",
 "keyName": "projects/$KMS_PROJECT_ID/locations/$KMS_LOCATION/keyRings/$KMS_KEYRING/cryptoKeys/$KMS_KEY_NAME",
 "state": "ALL_OBJECTS_ENCRYPTION_ENABLED"
 }
}

Depending on the cluster API response, the expected values might also appear as state: ENCRYPTED and currentState: CURRENT_STATE_ENCRYPTED . The key finding is that encryption is enabled and databaseEncryption.keyName references the approved Cloud KMS CryptoKey. Updating an existing cluster can restart the control plane and re-encrypt existing data, so apply the change during an approved maintenance window, especially for zonal clusters.

Impact:

To use application layer Secrets encryption, the Kubernetes Engine Service Agent must have the Cloud KMS CryptoKey Encrypter/Decrypter role on the selected key. Enabling this feature on an existing cluster restarts the control plane and re-encrypts existing Secrets, which can result in a long running operation and temporary control plane unavailability for zonal clusters. Key availability, Cloud KMS permissions, rotation procedures, and Cloud KMS quota should be validated before enabling this control.

See Also

https://workbench.cisecurity.org/benchmarks/24958

Item Details

Category: IDENTIFICATION AND AUTHENTICATION, SYSTEM AND COMMUNICATIONS PROTECTION

References: 800-53|IA-5(1), 800-53|SC-28, 800-53|SC-28(1), CSCv7|14.8

Plugin: GCP

Control ID: c5ae48b0a6d844501dffb8b0850194b6eb696ea1a3ebe6977eaee94a49e80648