Examkin

Question

Difficulty: Very hardSecrets Management and Service Account Lifecycle Security

An organization is implementing a zero-trust credential architecture to allow workloads running on an external on-premises Kubernetes cluster to retrieve sensitive credentials stored in Google Cloud Secret Manager. To comply with strict security standards, you must eliminate all static, long-lived service account keys and enforce least privilege. Arrange the operational and architectural steps in the correct chronological order required to establish Workload Identity Federation and securely retrieve the secret payload.

  1. 1Create a dedicated Google Cloud Service Account and grant it the Secret Manager Secret Accessor (`roles/secretmanager.secretAccessor`) IAM role scoped strictly to the target secret resource.
  2. 2Create a Workload Identity Pool and configure an OIDC Workload Identity Provider specifying the external Kubernetes cluster issuer URL and target audience.
  3. 3Grant the Workload Identity User (`roles/iam.workloadIdentityUser`) role on the Google Cloud Service Account to the specific external principal subject (`principal://...`).
  4. 4Exchange the external Kubernetes Service Account OIDC JSON Web Token (JWT) for a short-lived Google Cloud Security Token Service (STS) token, and generate a federated access token.
  5. 5Call the Secret Manager API (`secrets.versions.access`) using the short-lived access token to fetch the secret payload.

Answer

The correct sequence begins by creating the target Google Cloud Service Account with restricted Secret Manager Accessor permissions, followed by creating the Workload Identity Pool and OIDC Provider, granting the Workload Identity User role to the specific external principal subject, exchanging the external OIDC token for a short-lived GCP token via STS, and finally accessing the secret payload.
The sequence follows the compulsory architectural workflow for Workload Identity Federation: first defining the GCP service account with least privilege permissions, establishing the external trust boundary via Workload Identity Pool and Provider, binding the federated principal to the service account via Workload Identity User role, performing the runtime token exchange with STS, and using the resulting temporary token to access Secret Manager.

Step-by-Step Solution

1
Provision the Google Cloud identity and grant resource-level permissions.
A dedicated Service Account exists with `roles/secretmanager.secretAccessor` granted specifically on the required secret resource.
Before external access can be granted, the target identity and its least-privilege access permissions must exist inside GCP.
2
Define external identity trust mechanisms in GCP IAM.
A Workload Identity Pool and OIDC Provider are established, pointing to the external Kubernetes issuer URL.
GCP must be configured to validate tokens signed by the external OIDC identity provider.
3
Configure IAM impersonation policy for federated principals.
The external workload identity subject is bound to the GCP Service Account via `roles/iam.workloadIdentityUser`.
This establishes the authorization bridge enabling the specific external pod identity to impersonate the GCP Service Account.
4
Execute runtime token exchange via Security Token Service (STS).
The workload obtains a short-lived GCP access token in exchange for its native Kubernetes service account JWT.
Workload Identity Federation relies on short-lived STS credential exchange rather than stored service account keys.
5
Access secret payload using short-lived credentials.
The workload successfully authenticates to Secret Manager and retrieves the secret data.
The temporary access token provides the necessary identity authorization to perform the API call.

Key Concept

Workload Identity Federation & Service Account Key Elimination
Rate this question

Topics

Secrets Management and Service Account Lifecycle Security

More questions from this topic