Examkin

Question

Difficulty: HardSecrets Management and Service Account Lifecycle Security

An organization is architecting a multi-tenant microservices platform hosted on Google Kubernetes Engine (GKE). Each microservice requires access to third-party API credentials stored in Secret Manager. To satisfy strict enterprise governance standards, all secret versions stored in Secret Manager must be encrypted using Customer-Managed Encryption Keys (CMEK) managed in a dedicated central KMS project, and pods must authenticate without using long-lived downloadable service account JSON keys. Which implementation design best meets these security requirements while enforcing least privilege?

  1. Configure GKE Workload Identity to map Kubernetes service accounts to dedicated GCP service accounts. Grant each GCP service account the Secret Manager Secret Accessor role on its respective secret, and grant the Secret Manager Service Agent in the application project the Cloud KMS CryptoKey Encrypter/Decrypter role on the CMEK key.Answer
  2. B
    Grant the GCP service accounts associated with the GKE workloads the Service Account Admin role so they can dynamically provision ephemeral keys and decrypt Secret Manager payloads directly from Cloud KMS.
  3. C
    Assign the Editor primitive role at the project level to the GKE node pool default service account so all pod workloads can read secrets and interact with Cloud KMS keys without configuring granular IAM bindings.
  4. D
    Configure Secret Manager to use Customer-Supplied Encryption Keys (CSEK) passed as raw base64-encoded strings inside pod environment variables to eliminate IAM key management dependencies in Cloud KMS.

Answer

Configure GKE Workload Identity to map Kubernetes service accounts to dedicated GCP service accounts, granting Secret Manager Secret Accessor to the workload service accounts and Cloud KMS CryptoKey Encrypter/Decrypter to the Secret Manager Service Agent.
The solution leveraging Workload Identity and proper IAM delegation satisfies all security requirements. Workload Identity allows Kubernetes service accounts to impersonate GCP service accounts without long-lived JSON keys. Granting the Secret Accessor role specifically to the workload service account enforces least privilege. Furthermore, because Secret Manager handles payload decryption transparently on behalf of authorized callers, granting the Cloud KMS CryptoKey Encrypter/Decrypter role to the Secret Manager Service Agent ensures secure CMEK operations without exposing key management permissions directly to the workload.

Step-by-Step Solution

1
Establish secure identity without key files
Enable GKE Workload Identity to bind Kubernetes Service Accounts (KSAs) to Google Cloud Service Accounts (GSAs), eliminating long-lived service account key files.
Workload Identity provides short-lived OpenID Connect (OIDC) tokens natively trusted by Google Cloud APIs.
2
Enforce least privilege secret payload access
Grant `roles/secretmanager.secretAccessor` strictly on the target secret resource to the GSA mapped to the workload.
Prevents microservices from accessing secrets intended for other applications.
3
Configure CMEK permission delegation
Grant `roles/cloudkms.cryptoKeyEncrypterDecrypter` on the central KMS key to the Secret Manager Service Agent (`service-PROJECT_NUMBER@gcp-sa-secretmanager.iam.gserviceaccount.com`).
Secret Manager performs envelope encryption/decryption operations on behalf of authorized callers, so the service agent requires KMS access rather than the individual microservice workloads.

Key Concept

GKE Workload Identity & Secret Manager CMEK IAM Delegation
Estimated Time:2m 0s
Rate this question

Topics

Secrets Management and Service Account Lifecycle Security

More questions from this topic