Examkin

Question

Difficulty: MediumSecrets Management and Service Account Lifecycle Security

A healthcare provider is deploying a microservice on Google Kubernetes Engine (GKE) in Google Cloud project `prod-apps`. The microservice requires read-only access to a database password stored securely in GCP Secret Manager located in a separate project, `prod-secrets`. Security governance policy strictly mandates eliminating long-lived service account JSON keys, enforcing least-privilege IAM permissions, and avoiding manual credential management inside pod environments. Which architectural approach satisfies these security and operational requirements?

  1. Enable GKE Workload Identity on the cluster, bind the Kubernetes Service Account to a dedicated GCP IAM Service Account in `prod-apps`, and grant the GCP IAM Service Account the Secret Manager Secret Accessor role on the specific secret in `prod-secrets`.Answer
  2. B
    Enable GKE Workload Identity on the cluster, bind the Kubernetes Service Account to a GCP IAM Service Account in `prod-secrets`, and grant that service account the Service Account Admin role in `prod-apps`.
  3. C
    Create a dedicated GCP IAM Service Account in `prod-secrets`, grant it the primitive Editor role on `prod-secrets`, and attach its service account email directly to the GKE node pool service account configuration.
  4. D
    Generate a JSON service account key for a GCP IAM Service Account in `prod-secrets`, store the key as a Kubernetes Secret in `prod-apps`, and mount the secret key file directly into the application container.

Answer

Enable GKE Workload Identity on the cluster, bind the Kubernetes Service Account to a dedicated GCP IAM Service Account in `prod-apps`, and grant the GCP IAM Service Account the Secret Manager Secret Accessor role on the specific secret in `prod-secrets`.
The solution leveraging GKE Workload Identity establishes keyless authentication between Kubernetes Pods and Google Cloud APIs. Granting `roles/secretmanager.secretAccessor` specifically on the target secret resource in project `prod-secrets` satisfies both cross-project access and least-privilege security requirements.

Step-by-Step Solution

1
Establish keyless identity federation
GKE Workload Identity maps the Kubernetes Service Account (KSA) to a GCP IAM Service Account (GSA) without requiring static JSON keys.
Eliminates long-lived service account key management and rotation overhead in compliance with security guidelines.
2
Configure cross-project IAM access control
Grant the GCP IAM Service Account the `roles/secretmanager.secretAccessor` role on the target secret in project `prod-secrets`.
Enforces least-privilege read access strictly limited to the required secret resource.

Key Concept

Workload Identity and Cross-Project Least-Privilege Secret Access
Rate this question

Topics

Secrets Management and Service Account Lifecycle Security

More questions from this topic