Question

Difficulty: MediumSecrets Management and Service Account Lifecycle Security

A logistics company utilizes an external GitHub Actions CI/CD runner to deploy microservices to Google Cloud. The deployment pipeline requires access to sensitive environment parameters stored in Secret Manager. Company security policy strictly forbids generating, downloading, or storing long-lived service account JSON keys. Which TWO architectural recommendations should you implement to satisfy these requirements securely while adhering to least privilege? (Select TWO.)

  1. Configure Workload Identity Federation using OpenID Connect (OIDC) to exchange short-lived external GitHub tokens for Google Cloud service account federated credentials.Answer
  2. B
    Export a service account JSON key file, encode it in base64, and store it as an encrypted repository secret within GitHub Actions for pipeline authentication.
  3. Grant the target service account the Secret Manager Secret Accessor role (roles/secretmanager.secretAccessor) bound specifically to the required secret resources.Answer
  4. D
    Assign the primitive Editor role (roles/editor) to the service account at the project level to simplify access across all Secret Manager resources.
  5. E
    Assign the Service Account Admin role (roles/iam.serviceAccountAdmin) to the deployment service account so it can provision temporary access keys dynamically.

Answer

The correct architecture requires setting up Workload Identity Federation using OpenID Connect (OIDC) to exchange short-lived tokens and granting the target service account the Secret Manager Secret Accessor role bound specifically to the required secret resources.
To secure external CI/CD pipelines without exposing long-lived credentials, Google Cloud recommends using Workload Identity Federation with OpenID Connect (OIDC). This configuration allows the external runner to present short-lived identity tokens in exchange for federated GCP service account access tokens. Additionally, adhering to the principle of least privilege requires granting fine-grained roles—specifically Secret Manager Secret Accessor—directly on the required secret objects rather than applying broad project-level permissions.

Step-by-Step Solution

1
Establish keyless authentication between the external CI/CD system and Google Cloud.
Workload Identity Federation authenticates GitHub Actions via short-lived OIDC tokens without requiring static JSON service account keys.
Eliminates the risk of long-lived credential leakage in external systems.
2
Apply fine-grained IAM permissions to the target service account.
The Secret Manager Secret Accessor role (`roles/secretmanager.secretAccessor`) is granted only on the specific secret resources needed by the pipeline.
Ensures the service account has only the permissions required to read secret payloads without project-wide or administrative access.

Key Concept

Keyless authentication with Workload Identity Federation combined with resource-level IAM roles for secrets management.
Rate this question