SkarpChapter 23 of 26
Service Accounts and Workload Identity: Secure Access for Applications
Secure your workloads with correctly scoped service accounts, key management, and impersonation patterns that appear frequently on the exam.
Big Picture: Why Service Accounts Matter
From IAM to Service Accounts
IAM controls who has what access to which resource. Now we focus on the most important non-human identity in Google Cloud: the service account.
Canonical Definition
A service account is a special kind of account used by an application or compute workload, not a person, to make authorized API calls and access Google Cloud resources.
Robot Users
Think of a service account as a robot user with its own email-like ID. Workloads run as this identity and get tokens to call Google APIs.
Exam-Relevant Skills
You must know when to use service vs user accounts, how to attach them to workloads, avoid long-lived keys, and prefer keyless, short-lived credentials.
Anatomy of a Service Account
Core Attributes
Service accounts have a display name, an email-like ID, belong to a project, hold credentials, and appear in IAM bindings.
What It Can Do
You grant roles to the service account on resources. Example: roles/storage.objectViewer on a bucket so the workload can read objects.
Who Can Use It
You also grant roles on the service account itself. Example: roles/iam.serviceAccountUser so a user can attach it to a VM.
Exam Trap
Exam items often confuse "what the SA can do" with "who can use the SA". Read carefully which direction the question is about.
Creating and Managing Service Accounts (Console & gcloud)
Scenario Setup
Project my-project. A VM app needs read-only access to a single Cloud Storage bucket: gs://app-config-bucket.
Step 1: Create SA
In console, create service account app-config-reader. With gcloud: gcloud iam service-accounts create app-config-reader --display-name="App Config Reader".
Step 2: Grant Bucket Access
Use gsutil iam ch to grant objectViewer (roles/storage.objectViewer) to the service account on just gs://app-config-bucket.
Step 3: Let Admins Use SA
Grant roles/iam.serviceAccountUser on the service account to a small admin group so they can attach it to VMs.
Service Account Keys vs Keyless Access
What Are SA Keys?
Service account keys are long-lived JSON private key files that let code anywhere authenticate as the service account.
Why Keys Are Risky
They are long-lived, hard to rotate, and easy to leak (commits, tickets, logs). If leaked, attackers can impersonate your app.
Keyless Access
On Google-managed compute, attach a service account. The platform issues short-lived tokens via metadata; code uses ADC, no keys needed.
Exam Signal
If a question offers JSON key files vs attached service accounts or Workload Identity, prefer the managed, keyless option.
Service Account Impersonation and Short-Lived Credentials
What Is Impersonation?
A caller (user or service account) obtains a short-lived token that lets it act as another service account, if IAM allows it.
How It Works
Caller must have roles/iam.serviceAccountTokenCreator on the target SA. Google issues a short-lived token representing the target SA.
Benefits
No long-lived keys, centralize sensitive roles, and better audit logs showing who impersonated which service account.
CI/CD Example
A low-privilege ci-runner-sa impersonates prod-deployer-sa only during deployments, using serviceAccountTokenCreator.
Attaching Service Accounts to Compute Engine VMs
Default SA on VMs
Compute Engine often uses a default service account. Historically it had broad Editor rights, which is now considered bad practice.
Best Practice Pattern
Create a dedicated service account per app, grant minimal roles, and attach that service account to the VM.
Console Attachment
When creating a VM, expand advanced settings, pick your custom service account, and rely on IAM roles instead of legacy access scopes.
Exam Trap
Avoid solutions that give the default VM service account Editor on the project; prefer least-privilege custom service accounts.
Service Accounts with GKE, Cloud Run, and Cloud Functions
GKE Identities
GKE has node service accounts (VM level) and Workload Identity that maps Kubernetes SAs to Google SAs for per-pod permissions.
Workload Identity
Recommended for GKE: avoid keys, give each pod a distinct Google Cloud identity via KSA↔GSA mapping.
Cloud Run Runtime SA
Cloud Run services run as a runtime service account. Override the default with a dedicated SA per service and minimal roles.
Cloud Functions Runtime SA
Cloud Functions also run as a runtime SA. Set a custom SA per function to match its responsibility and follow least privilege.
Thought Exercise: Choosing the Right Service Account Pattern
Work through these mini-scenarios mentally. After each one, pause and decide:
1) What service account should be used?
2) How should it be attached?
3) Are keys needed or can you stay keyless?
Scenario A: Cloud Run to Cloud Storage
You have a Cloud Run service that generates reports and writes them to a specific Cloud Storage bucket.
- What is the best service account strategy?
- Which IAM role(s) does it need, and at what scope?
- Is there any reason to download a JSON key?
Think it through, then compare:
- Likely answer: a dedicated runtime service account for this Cloud Run service (for example, `report-writer-sa`). Grant it `roles/storage.objectCreator` (or `objectAdmin` if it must list/delete) on only that bucket. No keys; just set the runtime service account in Cloud Run.
Scenario B: GKE microservices accessing Pub/Sub
You run multiple microservices on GKE, each publishing to different Pub/Sub topics.
- How do you avoid all pods sharing the node's service account?
- How do you keep permissions isolated per microservice?
Likely pattern:
- Enable Workload Identity.
- Create a Google service account per microservice (for example, `billing-publisher-sa`).
- Create Kubernetes service accounts and map each to its Google SA.
- Grant each Google SA `roles/pubsub.publisher` on its specific topic.
Scenario C: CI/CD deploying to prod
Your CI pipeline (running on Cloud Build or a runner VM) needs to deploy to a locked-down production project.
- Do you give the CI runner broad roles directly? Or use impersonation?
Preferred pattern:
- Create a powerful `prod-deployer-sa` in the prod project.
- Grant your CI runner SA `roles/iam.serviceAccountTokenCreator` on `prod-deployer-sa`.
- CI impersonates `prod-deployer-sa` only for deployment steps.
As you review, ask yourself: in each scenario, did you avoid long-lived keys and choose the narrowest necessary roles?
Quiz 1: Fundamentals of Service Accounts
Answer this question to check your understanding of core service account concepts.
A team is deploying a new Cloud Run service that reads from a Cloud Storage bucket. They are not sure how to authenticate. Which option follows Google Cloud best practices as of 2026?
- Download a JSON key for the project owner account and bake it into the container image so the service can access any resource it needs.
- Use the default Compute Engine service account with the Owner role at the project level so the Cloud Run service will not fail due to missing permissions.
- Create a dedicated service account for the Cloud Run service, grant it Storage Object Viewer on the specific bucket, and configure the service to run as that service account.
- Enable anonymous access on the bucket so that the Cloud Run service does not need any credentials.
Show Answer
Answer: C) Create a dedicated service account for the Cloud Run service, grant it Storage Object Viewer on the specific bucket, and configure the service to run as that service account.
The correct answer is to create a dedicated service account for the Cloud Run service, grant it the minimal required role (such as roles/storage.objectViewer) on the specific bucket, and configure the runtime service account accordingly. This is keyless, least-privilege, and aligns with current best practices. Using JSON keys, broad Owner roles, or anonymous access all violate security and exam expectations.
Quiz 2: Impersonation and Permissions Direction
Test your understanding of who can use a service account vs what it can do.
You created a service account `backup-sa` that has Storage Object Admin on a backup bucket. A DevOps engineer needs to attach `backup-sa` to a new VM. Which additional IAM role must you grant, and on which resource?
- Grant the engineer Storage Object Admin on the bucket so they can attach `backup-sa` to the VM.
- Grant the engineer roles/iam.serviceAccountUser on the `backup-sa` service account so they can attach it to the VM.
- Grant the engineer roles/iam.serviceAccountTokenCreator on the project so they can use any service account.
- Grant the engineer roles/compute.instanceAdmin on the VM so they automatically gain the ability to attach any service account.
Show Answer
Answer: B) Grant the engineer roles/iam.serviceAccountUser on the `backup-sa` service account so they can attach it to the VM.
To allow a user to attach a specific service account to a VM, you grant them roles/iam.serviceAccountUser on that service account. Storage roles on the bucket control data access, not who can use the service account. roles/iam.serviceAccountTokenCreator is for impersonation tokens, and compute.instanceAdmin alone does not automatically grant permission to use arbitrary service accounts.
Key Term Review: Service Accounts and Workload Identity
Flip through these cards to reinforce key concepts before moving on.
- service account (canonical definition)
- A service account is a special kind of account used by an application or compute workload, not a person, to make authorized API calls and access Google Cloud resources.
- Identity and Access Management (IAM) (canonical definition)
- Identity and Access Management (IAM) lets you manage access control by defining who (identity) has what access (role) for which resource.
- Least privilege for service accounts
- Grant service accounts only the roles they need, ideally at the narrowest scope (specific bucket, topic, or project), and avoid broad roles like Owner or Editor unless absolutely necessary.
- Service account key
- A long-lived private key (typically JSON) for a service account that allows external code to authenticate as that account. As of 2026, this is discouraged for most workloads in favor of keyless, short-lived credentials.
- Keyless access
- An authentication model where workloads obtain short-lived tokens from the Google Cloud metadata server or Workload Identity, without storing long-lived service account key files.
- Service account impersonation
- A pattern where a caller (user or service account) with roles/iam.serviceAccountTokenCreator on a target service account obtains short-lived credentials to act as that target service account.
- roles/iam.serviceAccountUser
- An IAM role that lets a principal attach a service account to resources (like VMs or Cloud Run services) and act as that service account in certain contexts.
- roles/iam.serviceAccountTokenCreator
- An IAM role that lets a principal generate short-lived tokens to impersonate a service account, often used in CI/CD and cross-project scenarios.
- Runtime service account (Cloud Run / Cloud Functions)
- The service account that a Cloud Run service or Cloud Function executes as. It determines what Google Cloud resources the code can access.
- Workload Identity on GKE
- A mechanism that maps Kubernetes service accounts to Google Cloud service accounts so pods can access Google APIs using keyless, short-lived credentials with per-pod permissions.
Key Terms
- keyless access
- An approach where workloads obtain short-lived tokens from Google Cloud (for example, metadata server or Workload Identity) without storing long-lived keys.
- least privilege
- A security principle where identities (including service accounts) are granted only the minimum permissions necessary to perform their tasks.
- service account
- A service account is a special kind of account used by an application or compute workload, not a person, to make authorized API calls and access Google Cloud resources.
- service account key
- A long-lived private key (usually JSON) associated with a service account, historically used to authenticate from outside Google Cloud, but now discouraged due to security risk.
- Workload Identity (GKE)
- A GKE feature that maps Kubernetes service accounts to Google Cloud service accounts, enabling per-pod, keyless access to Google APIs.
- runtime service account
- The service account under which a managed compute service (such as Cloud Run or Cloud Functions) executes, controlling its access to Google Cloud resources.
- roles/iam.serviceAccountUser
- An IAM role that allows a principal to attach and use a specific service account on resources such as VMs or Cloud Run services.
- service account impersonation
- A mechanism allowing a caller with appropriate IAM roles to obtain short-lived credentials to act as another service account.
- Identity and Access Management (IAM)
- Identity and Access Management (IAM) lets you manage access control by defining who (identity) has what access (role) for which resource.
- roles/iam.serviceAccountTokenCreator
- An IAM role that allows a principal to generate short-lived tokens that impersonate a service account.