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.

Iam Impersonation Short Lived Oidc Tokens | Professional Cloud Security Engineer

Iam Impersonation Short Lived Oidc Tokens

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

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.

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 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.

Professional Cloud Security Engineer

Iam Impersonation Short Lived Oidc Tokens

Related questions