Google Associate Cloud EngineerDeploying and implementing a cloud solutionHard
A company is deploying a new microservices application using Google Kubernetes Engine (GKE). Each microservice needs to communicate securely with other microservices and access specific Google Cloud APIs. They want to implement fine-grained authorization and avoid storing service account keys directly within the Pods. Which Google Cloud feature should be utilized for secure access management?
- ACloud IAM service account keys directly in Pods
- BNode Service Accounts
- CKubernetes Secrets
- DWorkload Identity
Show answer & explanationAnswer & explanation
Correct answer: D. Workload Identity
Workload Identity allows a Kubernetes service account to impersonate a Google Cloud service account. This provides fine-grained authorization for microservices to access Google Cloud APIs without needing to manage or distribute service account keys directly within Pods, enhancing security.
Why the other options are wrong
- A. Storing Cloud IAM service account keys directly in Pods is an anti-pattern as it increases the risk of key exposure and complicates key rotation and management.
- B. Node Service Accounts grant permissions to the underlying VM nodes, not typically for fine-grained access for individual microservices running in Pods.
- C. Kubernetes Secrets are for storing sensitive data like API keys, but Workload Identity is a more secure and native way to grant GCP access to GKE workloads without managing keys.
Workload Identity
A feature in GKE that allows Kubernetes service accounts to act as Google Cloud service accounts. This enables Pods to securely access Google Cloud services without needing to store or manage service account keys.
- Binds Kubernetes SA to Google Cloud SA.
- Eliminates need for explicit service account keys.
- Provides fine-grained authorization.
- Enhances security posture for GKE workloads.
Memory trick: Workload Identity: Your Pods wear a GCP badge, no key needed.