An enterprise is eliminating long-lived service account keys across its development and CI/CD pipelines. A developer needs to invoke a private microservice deployed on Cloud Run (https://orders.example.com) directly from their local environment. The security requirements are: The authentication flow must use short-lived OpenID Connect (OIDC) ID tokens targeted specifically to the service URL. Access must follow the principle of least privilege by impersonating a dedicated privilege-bearing service account (order-invoker@corp-project.iam.gserviceaccount.com), which already possesses the Cloud Run Invoker role (roles/run.invoker). The solution must avoid granting broad token generation permissions or allowing credential persistence. Which IAM role and short-lived credential generation process should the security engineer implement?

Grant the developer the Service Account OpenID Connect Identity Token Creator role (roles/iam.serviceAccountOpenIdTokenCreator) on order-invoker, and generate an ID token by calling the IAM Credentials API generateIdToken endpoint with the target URL as the audience.: What the Service Account OpenID Connect Identity Token Creator role is The Service Account OpenID Connect Identity Token Creator role (roles/iam.serviceAccountOpenIdTokenCreator) contains the iam.serviceAccounts.getOpenIdToken permission. It specifically allows a principal (such as a developer user identity or CI/CD runner) to impersonate a target privilege-bearing service account exclusively for generating short-lived OIDC ID tokens without granting permissions to generate OAuth 2.0 access tokens or sign arbitrary data. How it meets the requirements Targeted OIDC ID tokens: Calling the generateIdToken method on the IAM Credentials API (iamcredentials.googleapis.com) allows the caller to pass the specific Cloud Run service URL in the audience (aud) claim. Cloud Run requires a Google-signed OIDC ID token matching the receiving service's URL to authenticate incoming requests. Least privilege impersonation: Granting roles/iam.serviceAccountOpenIdTokenCreator directly on the order-invoker service account resource (rather than at the project level) restricts the developer's impersonation capability strictly to that single identity and specifically to OIDC token creation. Eliminating long-lived keys: Short-lived ID tokens expire automatically after a limited duration (typically 1 hour) and cannot be renewed without repeating the authenticated impersonation request, completely removing the risk of leaked persistent JSON keys. Key advantages Granular authorization: Distinguishes OIDC ID token generation from broader token minting and cryptographic signing operations. Audience restriction: Ensures the generated token can only be accepted by the intended Cloud Run endpoint (https://orders.example.com) and is rejected by other Google APIs or services. Native auditability: Every token issuance event is logged in Cloud Audit Logs, capturing both the caller identity and the impersonated service account identity. Why this is optimal This approach directly satisfies all zero-trust requirements: it leverages short-lived identity federation, avoids static keys, strictly limits caller permissions to OIDC generation, and enforces proper cryptographic audience claims required by Cloud Run.

StudyCerts

Professional Cloud Security Engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Iam Impersonation Short Lived Oidc Tokens

Section: Managing service account impersonation.

An enterprise is eliminating long-lived service account keys across its development and CI/CD pipelines. A developer needs to invoke a private microservice deployed on Cloud Run (https://orders.example.com) directly from their local environment.

The security requirements are:

The authentication flow must use short-lived OpenID Connect (OIDC) ID tokens targeted specifically to the service URL.
Access must follow the principle of least privilege by impersonating a dedicated privilege-bearing service account (order-invoker@corp-project.iam.gserviceaccount.com), which already possesses the Cloud Run Invoker role (roles/run.invoker).
The solution must avoid granting broad token generation permissions or allowing credential persistence.

Which IAM role and short-lived credential generation process should the security engineer implement?

Grant the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) to order-invoker on itself to allow self-impersonation, and have the developer extract ID tokens directly from the Compute Engine metadata server.

Grant the developer the Service Account User role (roles/iam.serviceAccountUser) on order-invoker, and generate an access token by calling the IAM Credentials API generateAccessToken endpoint with the Cloud Run URL in the scope parameter.

Grant the developer the Service Account Key Admin role (roles/iam.serviceAccountKeyAdmin) on order-invoker to generate temporary JSON private keys configured with a 1-hour expiration timestamp.

Grant the developer the Service Account OpenID Connect Identity Token Creator role (roles/iam.serviceAccountOpenIdTokenCreator) on order-invoker, and generate an ID token by calling the IAM Credentials API generateIdToken endpoint with the target URL as the audience.

Professional Cloud Security Engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Iam Impersonation Short Lived Oidc Tokens

Section: Managing service account impersonation.

The security requirements are:

The authentication flow must use short-lived OpenID Connect (OIDC) ID tokens targeted specifically to the service URL.
Access must follow the principle of least privilege by impersonating a dedicated privilege-bearing service account (order-invoker@corp-project.iam.gserviceaccount.com), which already possesses the Cloud Run Invoker role (roles/run.invoker).
The solution must avoid granting broad token generation permissions or allowing credential persistence.

Which IAM role and short-lived credential generation process should the security engineer implement?

Grant the developer the Service Account Key Admin role (roles/iam.serviceAccountKeyAdmin) on order-invoker to generate temporary JSON private keys configured with a 1-hour expiration timestamp.

Explanations

What the Service Account OpenID Connect Identity Token Creator role is

The Service Account OpenID Connect Identity Token Creator role (roles/iam.serviceAccountOpenIdTokenCreator) contains the iam.serviceAccounts.getOpenIdToken permission. It specifically allows a principal (such as a developer user identity or CI/CD runner) to impersonate a target privilege-bearing service account exclusively for generating short-lived OIDC ID tokens without granting permissions to generate OAuth 2.0 access tokens or sign arbitrary data.

How it meets the requirements

Targeted OIDC ID tokens: Calling the generateIdToken method on the IAM Credentials API (iamcredentials.googleapis.com) allows the caller to pass the specific Cloud Run service URL in the audience (aud) claim. Cloud Run requires a Google-signed OIDC ID token matching the receiving service's URL to authenticate incoming requests.
Least privilege impersonation: Granting roles/iam.serviceAccountOpenIdTokenCreator directly on the order-invoker service account resource (rather than at the project level) restricts the developer's impersonation capability strictly to that single identity and specifically to OIDC token creation.
Eliminating long-lived keys: Short-lived ID tokens expire automatically after a limited duration (typically 1 hour) and cannot be renewed without repeating the authenticated impersonation request, completely removing the risk of leaked persistent JSON keys.

Key advantages

Granular authorization: Distinguishes OIDC ID token generation from broader token minting and cryptographic signing operations.
Audience restriction: Ensures the generated token can only be accepted by the intended Cloud Run endpoint (https://orders.example.com) and is rejected by other Google APIs or services.
Native auditability: Every token issuance event is logged in Cloud Audit Logs, capturing both the caller identity and the impersonated service account identity.

Why this is optimal

This approach directly satisfies all zero-trust requirements: it leverages short-lived identity federation, avoids static keys, strictly limits caller permissions to OIDC generation, and enforces proper cryptographic audience claims required by Cloud Run.

View source documentation

Professional Cloud Security Engineer

Iam Impersonation Short Lived Oidc Tokens

Professional Cloud Security Engineer

Iam Impersonation Short Lived Oidc Tokens

What the Service Account OpenID Connect Identity Token Creator role is

How it meets the requirements

Key advantages

Why this is optimal

Related questions