Professional Cloud Security EngineerConfiguring access within a cloud solution environmentMedium
A global enterprise uses Google Kubernetes Engine (GKE) for stateless microservices. They need to ensure that their GKE workloads can securely access other Google Cloud services (e.g., Cloud Storage, Cloud SQL) without embedding static service account keys within container images or Pods. The solution must follow the principle of least privilege and simplify credentials management. Which approach should the security engineer recommend?
- AUse Google Cloud Storage FUSE to mount Cloud Storage buckets directly into GKE Pods, handling authentication automatically.
- BGrant the `roles/editor` role to the default Compute Engine service account used by the GKE nodes.
- CCreate a dedicated service account key (JSON file) for each GKE Pod and mount it as a Kubernetes Secret.
- DConfigure Workload Identity on the GKE cluster to associate Kubernetes Service Accounts with Google Cloud Service Accounts.
Show answer & explanationAnswer & explanation
Correct answer: D. Configure Workload Identity on the GKE cluster to associate Kubernetes Service Accounts with Google Cloud Service Accounts.
Workload Identity allows Kubernetes Service Accounts to act as Google Cloud Service Accounts, enabling Pods to securely access Google Cloud resources without needing to store or manage service account keys. This aligns with least privilege and simplifies management.
Why the other options are wrong
- A. While GCS FUSE can mount buckets, it doesn't solve the underlying problem of how the Pod itself authenticates to Google Cloud to perform the mount or access other services.
- B. Granting `roles/editor` to the node's service account provides overly broad permissions to all Pods running on that node, violating the principle of least privilege.
- C. Embedding static service account keys in Pods or Secrets is a security anti-pattern and makes key rotation/management difficult.
Workload Identity (GKE)
Workload Identity enables Google Kubernetes Engine (GKE) applications to securely access Google Cloud services by allowing Kubernetes Service Accounts to impersonate Google Cloud Service Accounts.
- Eliminates the need to export and manage service account keys.
- Provides fine-grained, per-Pod permissions.
- Uses short-lived credentials, enhancing security.
- Requires enabling Workload Identity on the GKE cluster.
Memory trick: The Workload Identity Bridge: Kubernetes talks to Google Cloud securely.