Question

A financial services company runs sensitive workloads on a Google Kubernetes Engine (GKE) Standard cluster. During a compliance audit, the security team learns that Kubernetes Secrets (containing API tokens and database passwords) are stored in etcd only base64-encoded, not encrypted with a key the company controls. Regulators require that any at-rest secret material be protected by a customer-managed encryption key with the ability to disable access. What should the architect implement to meet this requirement with the least operational overhead?

Accepted Answer

Enable application-layer secrets encryption on the GKE cluster using a Cloud KMS key (CMEK) to envelope-encrypt Kubernetes Secrets in etcd.

Answer

Migrate all secrets out of Kubernetes and require every pod to fetch them at startup from Secret Manager over the internet.

Answer

Rely on GKE's default Google-managed encryption at rest for etcd, since all data on persistent disks is already encrypted.

Answer

Deploy a HashiCorp Vault cluster inside GKE and store its unseal keys as Kubernetes Secrets to protect the other secrets.