SkarpChapter 24 of 27
service accounts, Workload Identity, and Secure Service-to-Service Access
Applications and workloads need identities too; learn how to configure service accounts and workload identities securely across compute platforms.
Service Accounts: Giving Workloads an Identity
Why Service Accounts?
Applications and workloads need identities too. In Google Cloud, this is handled by service accounts, which represent non-human actors like VMs, containers, and functions.
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.
Service Accounts vs Users
User accounts represent people; service accounts represent workloads. Users log in with passwords/SSO; workloads usually use tokens or (legacy) key files.
Tied to Compute Choices
Service accounts are central to Compute Engine, Google Kubernetes Engine, Cloud Run, and Cloud Functions. These workloads call APIs on behalf of a service account.
Two IAM Views
You must manage: 1) what the service account can do (its roles on resources), and 2) who can use or manage the service account (roles on the service account itself).
Creating and Managing Service Accounts Securely
Creating a Service Account
In the console: IAM & Admin → Service Accounts → Create service account, then set name/ID, grant needed roles, and optionally let people use this account.
Least Privilege
Grant only the roles the workload needs. Prefer predefined or custom roles. Avoid basic roles like `Editor` for service accounts.
Good Naming
Use names that show purpose and scope, like `sa-gce-prod-web-read-storage` or `sa-gke-staging-orders-api`, to make audits and reviews easier.
Lifecycle Management
Periodically review roles, disable or delete unused service accounts, and plan to migrate away from long-lived keys to safer patterns.
Exam Pattern
Most exam scenarios: create a dedicated service account, grant minimal roles, attach it to the workload, instead of using default accounts.
Service Accounts with Compute Engine, Cloud Run, and Cloud Functions
Compute Engine VMs
Each VM has one service account. Avoid the default; create a dedicated service account and attach it when creating the VM for least privilege.
Legacy Scopes vs IAM
Older docs mention OAuth scopes. Today, IAM roles on the service account and resources are the main control for what a VM can access.
Cloud Run Services
Every Cloud Run service runs as a service account. Change the default to a dedicated account and let the platform fetch tokens automatically.
Cloud Functions
Each Cloud Function has a service account. Use a specific account per function or microservice instead of reusing broad default accounts.
Key Exam Theme
Pattern: attach a properly scoped service account to the workload and avoid key files. Let the platform handle short-lived tokens for you.
Service Accounts with Google Kubernetes Engine (GKE)
Two Kinds of Service Accounts
In GKE: Kubernetes service accounts (KSA) live inside the cluster; Google Cloud service accounts (GSA) live in IAM and call Google Cloud APIs.
Legacy Pattern
Historically, pods used the node’s service account, giving all pods the same permissions and violating least privilege.
Workload Identity Idea
Workload Identity maps a KSA to a GSA. A pod using that KSA gets credentials that act as the mapped GSA when calling Google Cloud APIs.
Least Privilege in GKE
Create different KSAs and GSAs for different microservices or namespaces, each with only the roles it needs.
Exam Signal
If a question is about securing GKE access to Google APIs, the preferred answer is usually to configure Workload Identity, not node-level service accounts.
Service Account Keys, Impersonation, and Short-Lived Credentials
What Are Service Account Keys?
Keys are JSON files containing a private key that lets you authenticate as a service account. They are long-lived secrets and risky if leaked.
Risks of Keys
If a key is exposed, attackers can act as that service account until you revoke the key. Keys often end up in logs or Git repos by mistake.
Impersonation
With impersonation, a trusted identity gets permission to act as a service account and obtains short-lived tokens instead of long-lived keys.
Short-Lived Credentials
Short-lived access or ID tokens expire quickly, shrinking the attack window and aligning with modern security expectations.
Exam Preference
If you can choose between JSON key files and impersonation with short-lived tokens, the secure, exam-correct choice is impersonation.
Hands-On: Using Service Account Impersonation with gcloud
This step shows practical `gcloud` commands you might see in exam-style scenarios, especially around CI/CD or admin tasks. You do not need to memorize every flag, but you should understand the flow: grant impersonation permissions, then request short-lived tokens.
Imagine you have:
- Target service account: `sa-prod-deployer@PROJECT_ID.iam.gserviceaccount.com`
- Your admin user or CI/CD service account: `cicd@PROJECT_ID.iam.gserviceaccount.com`
1. Grant impersonation rights (one-time IAM setup):
You (as a project owner or IAM admin) allow the CI/CD account to impersonate the deployer service account:
```bash
Grant Service Account Token Creator to CI/CD on the target SA
gcloud iam service-accounts add-iam-policy-binding \
sa-prod-deployer@PROJECT_ID.iam.gserviceaccount.com \
--member="serviceAccount:cicd@PROJECT_ID.iam.gserviceaccount.com" \
--role="roles/iam.serviceAccountTokenCreator"
```
2. CI/CD pipeline impersonates the service account:
Instead of storing a JSON key, the pipeline uses impersonation to get a short-lived token and then deploys resources:
```bash
Print an access token for the target service account
gcloud auth print-access-token \
--impersonate-service-account=sa-prod-deployer@PROJECT_ID.iam.gserviceaccount.com
Use impersonation directly with another gcloud command
gcloud run deploy my-service \
--image=gcr.io/PROJECT_ID/my-image:latest \
--region=us-central1 \
--impersonate-service-account=sa-prod-deployer@PROJECT_ID.iam.gserviceaccount.com
```
Key idea for the exam: No JSON key is created or stored. Access is controlled centrally via IAM and tokens are short-lived. If you see a multiple-choice option that suggests downloading a key to a build server, that is usually the wrong answer compared with impersonation.
Workload Identity on GKE: Conceptual Flow
Goal of Workload Identity
Let GKE pods call Google Cloud APIs securely without node-wide credentials or JSON keys, using a mapping from KSA to GSA.
High-Level Steps
Enable Workload Identity, create a GSA with minimal roles, create a KSA, bind KSA to GSA, and run pods using that KSA.
IAM Binding
Grant the KSA `roles/iam.workloadIdentityUser` on the GSA so it can act as that GSA when accessing Google Cloud APIs.
Runtime Behavior
Pods get projected tokens that the control plane exchanges for access tokens representing the GSA, all without key files.
Why It Matters
This pattern enforces least privilege per workload and is the preferred answer for securing GKE workloads on the exam.
Workload Identity: YAML and IAM Snippets
IAM Binding Snippet
Use `gcloud iam service-accounts add-iam-policy-binding` to grant the KSA `roles/iam.workloadIdentityUser` on the GSA.
KSA Annotation
In the KSA YAML, annotate with `iam.gke.io/gcp-service-account: "GSA_EMAIL"` so Workload Identity knows which GSA to use.
Pod Uses the KSA
In the Pod spec, set `serviceAccountName: ksa-payments-api`. The pod then gets tokens mapped to the GSA automatically.
No Keys Needed
The container image and manifests contain no JSON keys. Credentials are short-lived and managed by the platform.
Exam Interpretation
When you see YAML plus IAM bindings like this, recognize it as Workload Identity, the recommended GKE access pattern.
Thought Exercise: Designing Least-Privilege Service Accounts
Work through this scenario mentally to solidify your design skills.
Scenario:
You are deploying a small application with three components in one project:
- A public-facing web frontend on Cloud Run.
- A backend API on Compute Engine that reads/writes to Cloud SQL.
- A batch job on Cloud Functions that reads messages from Pub/Sub and writes reports to a Cloud Storage bucket.
Task: For each component, decide:
- Should you use the default service account or a dedicated one?
- What kind of IAM roles should that service account have (broad vs specific)?
- Are service account keys needed?
Pause and outline your design before revealing the suggested approach.
Suggested approach:
- Cloud Run frontend
- Create a dedicated service account `sa-cr-frontend`.
- Grant it only what it needs (maybe call the backend via HTTPS, so it might just need an ID token capability, or minimal logging roles).
- Attach `sa-cr-frontend` to the Cloud Run service; no keys.
- Compute Engine backend
- Create `sa-gce-backend`.
- Grant it Cloud SQL Client role and any storage/logging roles required.
- Attach it to the VM at creation; avoid default service account and keys.
- Cloud Functions batch job
- Create `sa-cf-reporter`.
- Grant Pub/Sub Subscriber on the relevant subscription and Storage Object Admin (or a narrower role) on the reports bucket.
- Configure the function to run as this account; again, no keys.
Reflect: Where did you apply least privilege? Where did you avoid risky patterns like broad basic roles or JSON keys?
Quiz 1: Core Service Account Concepts
Test your understanding of basic service account behavior and best practices.
Which statement best describes how you should typically give a Cloud Run service access to read from a specific Cloud Storage bucket?
- Create a JSON key for the project Owner account, store it in the container image, and use it to authenticate.
- Use the default Compute Engine service account and grant it the Storage Admin role at the project level.
- Create a dedicated service account, grant it a specific Storage role on the target bucket, and configure the Cloud Run service to run as that account.
- Grant all authenticated users the Storage Object Viewer role on the bucket so the service can read objects without a service account.
Show Answer
Answer: C) Create a dedicated service account, grant it a specific Storage role on the target bucket, and configure the Cloud Run service to run as that account.
The secure, least-privilege pattern is to create a dedicated service account, grant it a specific Storage role (for example, Storage Object Viewer) on the bucket, and attach it to the Cloud Run service. Using JSON keys, broad project-level roles, or public-style access is not recommended and would be incorrect on the exam.
Quiz 2: Workload Identity and Keys
Check your understanding of Workload Identity and key risks.
You manage a GKE cluster and want each microservice to access only the specific Google Cloud resources it needs, without storing JSON keys. What is the recommended approach?
- Use the node's Compute Engine default service account and give it Owner on the project.
- Create one shared Google Cloud service account with broad roles and mount its JSON key into all pods.
- Enable Workload Identity, create separate Google Cloud service accounts with minimal roles, and map each Kubernetes service account to a corresponding Google Cloud service account.
- Disable IAM for the project so that pods can access all APIs without authentication.
Show Answer
Answer: C) Enable Workload Identity, create separate Google Cloud service accounts with minimal roles, and map each Kubernetes service account to a corresponding Google Cloud service account.
Workload Identity lets you securely map Kubernetes service accounts to Google Cloud service accounts, each with minimal roles, and avoids JSON keys. Using node-wide credentials, shared keys, or disabling IAM breaks least privilege and is not aligned with current best practices or the exam expectations.
Key Term Review: Service Accounts and Workload Identity
Use these flashcards to reinforce the most important definitions and patterns.
- 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.
- Least privilege for service accounts
- Grant each service account only the specific predefined or custom roles it needs on specific resources, avoid project-level basic roles like Editor, and use separate service accounts for different applications or trust boundaries.
- Service account key risk
- JSON key files are long-lived secrets. If leaked, an attacker can act as the service account until the key is revoked. Modern best practice is to avoid keys and use impersonation or platform-managed short-lived tokens.
- Service account impersonation
- A pattern where a user or service account with roles like roles/iam.serviceAccountTokenCreator obtains short-lived tokens to act as another service account, without needing to download a key file.
- Workload Identity (GKE)
- A mechanism that maps Kubernetes service accounts to Google Cloud service accounts so that GKE workloads can obtain short-lived credentials to call Google Cloud APIs without node-wide credentials or JSON keys.
- GKE KSA vs GSA
- A Kubernetes service account (KSA) is an identity inside the cluster for pods. A Google Cloud service account (GSA) is an IAM identity used to call Google Cloud APIs. Workload Identity links a KSA to a GSA.
- Attaching service accounts to compute
- Compute Engine, Google Kubernetes Engine, Cloud Run, and Cloud Functions all let you specify which service account the workload runs as; the platform then obtains access tokens automatically for that account.
- IAM views for a service account
- 1) Roles the service account has on resources (what it can do). 2) Roles others have on the service account (who can use or manage it), such as Service Account User or Service Account Token Creator.
Key Terms
- least privilege
- A security principle where identities (including service accounts) are granted only the minimal permissions required to perform their tasks, and no more.
- 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.
- Workload Identity
- A Google Cloud feature for GKE that maps Kubernetes service accounts to Google Cloud service accounts so pods can obtain short-lived credentials for Google Cloud APIs without node-wide credentials or JSON keys.
- service account key
- A long-lived JSON key file containing a private key that allows authentication as a service account; now considered risky and generally discouraged.
- service account impersonation
- An access pattern where an identity with roles like roles/iam.serviceAccountTokenCreator obtains short-lived tokens to act as a service account instead of using downloaded keys.
- Kubernetes service account (KSA)
- An identity inside a Kubernetes cluster used by pods to authenticate to the Kubernetes API and, with Workload Identity, to external services.
- Google Cloud service account (GSA)
- A service account resource in Google Cloud IAM used as an identity to call Google Cloud APIs and access resources.
- Compute Engine default service account
- The automatically created service account often used by default for Compute Engine VMs and other workloads; best practice is to replace it with dedicated, minimally scoped service accounts.