Professional Cloud Security Engineer
Prepare and test your skills
Prepare and test your skills
A sequence diagram with four lifelines — Originating Principal, IAM Credentials API, Target Service Account, and Protected Resource. The animation shows the principal requesting a short-lived token via generateAccessToken, the API minting the token through impersonation of the privilege-bearing target service account, the token being returned, and the principal performing a resource action, ending with a Cloud Audit Logs note explaining principalEmail and serviceAccountDelegationInfo.
The Service Account Token Creator role allows an identity to directly assume a service account from anywhere by generating short-lived access tokens, identity tokens, and signatures. In contrast, the Service Account User role permits a caller to attach the service account to compute resources like virtual machines or build jobs without granting permission to mint tokens on demand.
Cloud Audit Logs record the actual human operator or originating system inside the service account delegation info metadata structure, while the principal email field records the target service account. Analysts identify the true originating caller during investigations by inspecting the earliest entry in this delegation chain.
Granting impersonation roles at the project level allows a user to impersonate every service account within that project boundary. Applying the role directly to a specific target service account restricts delegation exclusively to that identity, ensuring human operators only access the exact permissions required for their workload.
Service account impersonation replaces permanent credentials by issuing short-lived credentials that expire automatically after a set duration. The IAM Credentials API generates OAuth 2.0 access tokens for API authorization, OIDC ID tokens for identity verification, and cryptographic signatures for data payloads. Developers can invoke impersonation locally by passing the --impersonate-service-account flag in the Google Cloud CLI, while automated workloads query the local instance metadata server. CI/CD pipelines can also request temporary tokens directly through API methods like generateAccessToken and generateIdToken to avoid embedding static keys in configuration files.
Impersonation creates a direct relationship between the calling identity and the target privilege-bearing service account. To establish this delegation path, the caller must hold specific permissions such as iam.serviceAccounts.getAccessToken, iam.serviceAccounts.signBlob, or iam.serviceAccounts.getOpenIdToken. Workloads running outside Google Cloud should pair this workflow with Workload Identity Federation rather than storing private keys. Security policies must strictly block self-impersonation, a misconfiguration where a service account mints tokens for itself and creates an endless token-refresh cycle that bypasses lifetime limits.
Security operations teams evaluate impersonated requests by analyzing entry fields in Cloud Audit Logs. When an identity acts through impersonation, the log records the target service account inside the principal email field because that identity authorized the underlying API call. The actual human operator or originating system is recorded inside the service account delegation info metadata structure. Analysts inspect the earliest entry in this delegation chain to identify the true originating caller during incident investigations.
StudyCerts
StudyCerts[Originating Principal] -> [Delegation Chain / Impersonation] -> [Target Service Account] -> [Resource Action]
Enterprise governance frameworks prevent credential leakage by enforcing strict guardrails across project hierarchies:
iam.disableServiceAccountKeyCreation constraint via the Organization Policy Service to block the export of static private keys.Administrators must grant impersonation roles directly on the individual target service account resource rather than at the project, folder, or organization level. Applying the Service Account Token Creator (roles/iam.serviceAccountTokenCreator) role or the Service Account OpenID Connect Identity Token Creator (roles/iam.serviceAccountOpenIdTokenCreator) role to an entire project allows the user to impersonate every service account within that boundary. Granting the role on the specific service account restricts delegation exclusively to that identity. This resource-level scoping ensures that human operators only access the exact permissions required for their specific workload.
Security architects must separate token generation permissions from workload attachment permissions to prevent unintended privilege escalation:
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:
order-invoker@corp-project.iam.gserviceaccount.com), which already possesses the Cloud Run Invoker role (roles/run.invoker).Which IAM role and short-lived credential generation process should the security engineer implement?