Examkin

Question

Difficulty: MediumSecrets Management and Service Account Lifecycle Security

An enterprise architecture team is designing security controls for a financial reporting application deployed on a Google Kubernetes Engine (GKE) cluster in project-app. The application needs to securely retrieve sensitive third-party API credentials stored in GCP Secret Manager within a central governance project named project-sec. The architecture requirements mandate eliminating long-lived service account JSON keys and enforcing strict principle of least privilege. Which TWO actions should the security team implement to fulfill these security requirements?

  1. Configure GKE Workload Identity by mapping the Kubernetes ServiceAccount in the cluster namespace to a dedicated Google Cloud Service Account in project-app.Answer
  2. Grant the Secret Manager Secret Accessor role (roles/secretmanager.secretAccessor) on the specific secret resource in project-sec to the dedicated Google Cloud Service Account.Answer
  3. C
    Generate a downloadable JSON service account key for a service account in project-sec and mount it as a Kubernetes Secret into the GKE pod volume.
  4. D
    Grant the primitive Editor role (roles/editor) on project-sec to the GKE node pool default compute service account.
  5. E
    Grant the Service Account Admin role (roles/iam.serviceAccountAdmin) to the application's service account so it can generate temporary impersonation tokens for project-sec.

Answer

To securely access secrets across GCP projects without using long-lived keys, the team must configure GKE Workload Identity to bind the Kubernetes service account to a dedicated Google Cloud service account, and grant that Google Cloud service account the Secret Manager Secret Accessor role on the specific secret resource.
Combining GKE Workload Identity with resource-level secret IAM bindings provides a completely keyless architecture that adheres to Google-recommended security standards. Workload Identity bridges Kubernetes service accounts to GCP service accounts automatically, and granting the Secret Manager Secret Accessor role directly on the secret resource ensures the workload cannot inspect or modify other secrets in the security project.

Step-by-Step Solution

1
Establish keyless identity authentication for the GKE workload.
GKE Workload Identity securely binds the Kubernetes ServiceAccount to a Google Cloud Service Account without managing or storing long-lived JSON keys.
Eliminates secret leakage vectors associated with static credentials.
2
Configure fine-grained access permissions across projects.
The dedicated Google Cloud Service Account in project-app is granted the roles/secretmanager.secretAccessor role on the specific secret in project-sec.
Enforces least privilege access restricted to the exact secret needed.

Key Concept

GKE Workload Identity and Least Privilege Secret Access
Rate this question

Topics

Secrets Management and Service Account Lifecycle Security

More questions from this topic