Configuring access · Topic 2 of 7
Securing Service Accounts and Service Account Keys
Secure Google Cloud service accounts: default accounts, when to use them, creating, disabling and authorizing them, and auditing or blocking keys.
- 6 min
- Create one user-managed service account per workload, with only the roles it needs.
- Default service accounts can get Editor; block the automatic grant with an organization policy.
- Service Account User attaches an account; Token Creator impersonates it. Grant both on the account.
What it is
A service account is an identity for a workload rather than a person. A VM, a Cloud Run service or a CI pipeline authenticates as a service account and receives the IAM roles granted to it.
Service accounts are both principals (they hold roles) and resources (someone needs permission to use them). Most service account incidents come from over-privileged default accounts and leaked keys.
How it works
Types of service accounts
| Type | Example | Who manages it |
|---|---|---|
| User-managed | app-backend@PROJECT_ID.iam.gserviceaccount.com | You create, grant and delete it |
| Default | Compute Engine default PROJECT_NUMBER-compute@developer.gserviceaccount.com, App Engine default PROJECT_ID@appspot.gserviceaccount.com | Created when the API is enabled; you manage its grants |
| Service agent | service-PROJECT_NUMBER@... accounts used by Google services | Google; you only grant it access, for example to a KMS key |
Securing default service accounts
Default service accounts can receive the Editor role on the project automatically. Any VM that uses one, with broad access scopes, can change almost anything in the project.
- Enforce the organization policy
iam.automaticIamGrantsForDefaultServiceAccountsso default accounts get no automatic role. - Create a dedicated, user-managed service account per workload with only the roles it needs.
- Do not attach the default account to new VMs; choose your own account at creation.
- Organizations created recently get several of these guardrails enforced by default, but verify rather than assume.
When a service account is the right identity
| Scenario | Identity to use |
|---|---|
| Code running on Compute Engine, GKE, Cloud Run or Cloud Run functions | An attached user-managed service account |
| A scheduled job or pipeline calling Google APIs | A dedicated service account for that job |
| A workload on AWS, Azure, on premises or in GitHub Actions | Workload Identity Federation, impersonating a service account or using direct access |
| An administrator doing occasional privileged work | The admin's own identity, temporarily impersonating a service account if needed |
| A person using the console | Never a service account |
Creating, disabling and authorizing
gcloud iam service-accounts create app-backend \
--display-name="Backend API" --project=prod-app
gcloud projects add-iam-policy-binding prod-app \
--member="serviceAccount:app-backend@prod-app.iam.gserviceaccount.com" \
--role="roles/cloudsql.client"
gcloud iam service-accounts disable app-backend@prod-app.iam.gserviceaccount.comDisable before you delete. A disabled account stops authenticating at once and can be re-enabled if something breaks; a deleted account can be undeleted only for a limited time, and a new account with the same name is a different principal.
Two roles on the service account itself control who can use it:
| Role | Lets the holder |
|---|---|
Service Account User (roles/iam.serviceAccountUser) | Attach the account to a VM, Cloud Run service or job, then act through that resource |
Service Account Token Creator (roles/iam.serviceAccountTokenCreator) | Create tokens for the account, which is impersonation |
Grant these on the individual service account, not on the project. On the project they cover every service account in it, including privileged ones.
Service account keys
A user-managed key is a long-lived private key file. Anyone who has the file can act as the account until the key is deleted, from anywhere, and a service account can hold up to 10 keys.
| Control | How |
|---|---|
| Block key creation | Organization policy iam.disableServiceAccountKeyCreation |
| Block uploading your own public keys | Organization policy iam.disableServiceAccountKeyUpload |
| Limit key lifetime when keys are allowed | Organization policy iam.serviceAccountKeyExpiryHours |
| Find unused accounts and keys | Activity Analyzer and service account insights in Policy Intelligence |
| See which key made a call | Cloud Audit Logs show the key ID in the authentication details |
| Find risky keys | Security Command Center findings for user-managed keys |
Mitigate by replacing keys with attached service accounts or Workload Identity Federation. If a key must exist, store it in Secret Manager, rotate it, and delete old keys rather than leaving them in place.
A worked example
A security review finds 40 projects where VMs run as the Compute Engine default account with Editor, and three JSON keys checked into a repository.
The engineer deletes the exposed keys at once, then enforces iam.disableServiceAccountKeyCreation and iam.automaticIamGrantsForDefaultServiceAccounts on the organization. Each application gets a dedicated service account with predefined roles, and Editor is removed from the default accounts after Policy Intelligence confirms nothing uses it.
How the exam asks about this
- "Developers must not be able to create long-lived credentials for service accounts anywhere in the organization." Enforce
iam.disableServiceAccountKeyCreationat the organization node. - "A developer must deploy Cloud Run services that run as a specific service account, and nothing more." Grant Service Account User on that one service account, plus a Cloud Run deploy role.
- "Find which service account keys have not been used in 90 days so they can be removed." Use Activity Analyzer or service account insights in Policy Intelligence.
What to remember for the exam
- Create one user-managed service account per workload, with only the roles it needs.
- Default service accounts can get Editor; block the automatic grant with an organization policy.
- Service Account User attaches an account; Token Creator impersonates it. Grant both on the account.
- Disable before delete; disabling is reversible and stops use at once.
- Keys are the last resort: block them with organization policy and prefer federation.
Granting Service Account User or Token Creator at project level lets the holder act as every service account in the project, including ones with Owner. Grant them on the single account.
Common mistakes
Fixing a default account by narrowing access scopes only. Scopes are a legacy limit on the VM's token. IAM roles decide access, so remove Editor and use a dedicated account.
Rotating a leaked key instead of deleting it. Creating a new key does not stop the old one working. Delete the exposed key, then find what used it in the audit logs.
Using a service account for human administrators. People should use their own identities, with short impersonation when needed, so actions stay traceable to a person.
Check yourself
What does the organization policy iam.automaticIamGrantsForDefaultServiceAccounts do?
It stops default service accounts from automatically receiving the Editor role when they are created.
Which role lets a user attach a service account to a VM, and where should it be granted?
Service Account User, granted on that specific service account rather than on the project.
Why disable a service account before deleting it?
Disabling stops it authenticating at once but can be reversed if a workload still needs it, while deletion is harder to undo.
Topic 2 of 7 in Configuring access
Test yourself on Configuring access
The full Google Cloud Professional Cloud Security Engineer question bank has 749 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Google Cloud. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.