Examkin

Question

Difficulty: HardSecrets Management and Service Account Lifecycle Security

An enterprise security architect is transitioning an external CI/CD pipeline hosted on Azure DevOps from legacy static service account keys to short-lived federated credentials using Workload Identity Federation to securely access Secret Manager secrets.

In which sequential order should the architect execute the steps to configure this keyless authentication and authorization workflow?

  1. 1Create a Workload Identity Pool and an OIDC Workload Identity Provider in Google Cloud configured with the Azure DevOps issuer URL and audience.
  2. 2Configure attribute mappings and assertion conditions on the Workload Identity Provider to validate claims such as repository ID and pipeline context.
  3. 3Grant the roles/iam.workloadIdentityUser IAM role on the target GCP Service Account to the specific external principal set derived from the mapped attributes.
  4. 4Grant the roles/secretmanager.secretAccessor IAM role to the target GCP Service Account on the specific secret resource in Secret Manager.
  5. 5Configure the Azure DevOps pipeline step to exchange its Azure OIDC JWT for a Google Cloud federated token and generate a short-lived GCP service account access token.

Answer

The correct sequence begins by creating the Workload Identity Pool and Provider, defining attribute mappings and conditions, assigning the workloadIdentityUser role to the external principal set on the target Service Account, granting the secretAccessor role to the Service Account on the secret, and finally executing the token exchange in the pipeline.
The sequence follows the logical dependency chain of Workload Identity Federation setup: first establishing trust via the Pool and Provider, defining mapped attribute conditions for security filtering, granting impersonation rights via workloadIdentityUser on the service account, granting least-privilege secret accessor permissions to the service account, and executing the client-side credential exchange.

Step-by-Step Solution

1
Establish the federated trust anchor by creating a Workload Identity Pool and an OIDC Provider.
Google Cloud STS is configured to accept tokens issued by the external Azure DevOps issuer.
You must create the pool and provider infrastructure before referencing them in attribute rules or IAM policy bindings.
2
Define attribute mappings and assertion conditions on the provider.
Claims from the Azure DevOps JWT are mapped to GCP principal attributes (e.g., google.subject, attribute.repository).
Attribute mappings establish fine-grained identity filters so only authorized repositories or environments can authenticate.
3
Bind roles/iam.workloadIdentityUser on the target Service Account to the mapped principal set.
The external workload identity is authorized to impersonate the specific GCP Service Account.
Workload Identity Federation relies on the workloadIdentityUser role on the service account resource to authorize impersonation.
4
Grant roles/secretmanager.secretAccessor to the GCP Service Account on the secret.
The Service Account gains least-privilege read access to Secret Manager secret versions.
The service account itself must possess resource-level authorization to read secret payloads.
5
Update the pipeline script to call the GCP Security Token Service (STS) and IAM Credentials API.
The pipeline acquires a short-lived access token and fetches secret values dynamically.
Credential exchange and secret fetching can only succeed after all underlying IAM roles and trust relationships are provisioned.

Key Concept

Workload Identity Federation and Service Account Lifecycle Security
Rate this question

Topics

Secrets Management and Service Account Lifecycle Security

More questions from this topic