IAM Roles for Securing Service Accounts

Resource hierarchy and policy inheritance in Google Cloud describe how access flows from the top of an organization down to single resources. Identity and Access Management (IAM) (opens in a new tab) controls who can do what on which resource by attaching allow policies to levels in the hierarchy. A role granted at a higher level is automatically inherited by everything below it, so where the binding is placed decides how broad the access becomes.

1.1Google Cloud Resource Hierarchy

The Google Cloud resource hierarchy is an ordered tree with the organization (opens in a new tab) at the top and single service resources at the bottom. The organization is the root and ancestor of all folders and projects, folders separate groups such as departments or production versus development, projects hold workloads, and service-specific resources such as Compute Engine instances, disks, subnetworks, or Cloud Storage buckets live inside projects. Access set on a container applies to everything it contains, while access set on a service-specific resource applies only to that resource.

A service account acts as a principal in this hierarchy in the same way as a user or group. When a service account receives a role on a folder or project, that service account can use the bundled permissions on every resource beneath that point unless a more restrictive control blocks it.

1.2How IAM Policy Inheritance Works

IAM policy inheritance is the rule that a child resource inherits the allow policies of its parent node. An allow policy attached to the organization is inherited by all child folders and projects, an allow policy attached to a folder is inherited by its projects, and an allow policy attached to a project is inherited by all its child resources. Inheritance flows only downward from ancestor to descendant, and an inherited grant cannot be edited from the child view.

To change an inherited grant, the administrator must go to the resource where the role was granted. Some resources do not support their own allow policies, so access must be granted on an ancestor. For example, to let a principal write logs to a log bucket with no allow policy, the administrator grants the Logs Bucket Writer role (roles/logging.bucketWriter) on the project that contains the log bucket.

1.3Granular Role Bindings to Prevent Over-Privileged Access

Granular role bindings are IAM grants placed at the lowest hierarchy level that still allows the work to be done. A broad grant at the organization or folder level gives a service account access across many projects, while a narrow grant on one project or one service-specific resource limits the blast radius to just that scope. Choosing the lower level enforces least privilege and prevents over-privileged access across projects and folders.

To keep service accounts isolated:

• Bind the role on the specific project or service-specific resource instead of the folder or organization when only one workload needs it.
• Choose a predefined role or custom role with only the needed permissions instead of the basic Owner, Editor, or Viewer roles, especially in production.
• Review container-level grants regularly because one high-level binding flows to every descendant project and resource.

Choose a container-level binding when a team or automation truly manages many projects, and choose a resource-level binding when only one function, instance, dataset, or bucket needs access.

1.4Effective Allow Policy and Viewing Access

The effective allow policy is the complete set of permissions for a resource, formed by the union of its own allow policy and the allow policies of all its ancestors. To understand who can access a resource, the administrator must view the resource policy plus the project, folder, and organization policies above it. Tools such as Policy Analyzer help verify this inherited access across the hierarchy, for example by showing which principals can access a service account or read a BigQuery dataset containing personally identifiable information (PII).

Application of the principle of least privilege means giving a service account only the permissions its workload needs to interact with specific Google Cloud resources. In Identity and Access Management (IAM) (opens in a new tab), access is controlled by IAM policies that grant roles to identities, and each role is a bundle of permissions that authorizes actions on a resource. For service accounts, which are identities used by applications and virtual machines rather than people, least privilege is applied by creating a dedicated account, selecting narrow roles, and attaching the account only where it is needed.

2.1Choosing the Smallest Effective Role

Choosing the smallest effective role means evaluating basic, predefined, and custom IAM roles and selecting the one that covers the required operations without extra access. Basic roles grant broad access across a project, predefined roles grant focused access for a specific service, and custom roles grant only a hand-picked set of permissions. In production, do not grant Owner, Editor, or Viewer to a service account, and instead grant a predefined or custom role that meets the workload need.

A least-privilege custom role contains only the permissions the integration must call. For example, an automation identity that manages identities can be limited to service-account and role management without granting data access.

2.2Building a Least-Privilege Custom Role

A least-privilege custom role is an IAM role that bundles only the specific iam.* permissions required for one purpose, such as the Google Cloud IAM integration used by Google Security Operations. The administrator creates the role in IAM and Admin > Roles with launch stage General Availability, adds only the needed permissions, and then grants that role to the integration service account. Because the role defines the outer boundary, the integration cannot perform actions outside its listed permissions even if it is compromised.

A custom role for service-account and role lifecycle management includes only management permissions:

• iam.serviceAccounts.list
• iam.serviceAccounts.create
• iam.serviceAccounts.get
• iam.serviceAccounts.getIamPolicy
• iam.serviceAccounts.setIamPolicy
• iam.serviceAccounts.disable
• iam.serviceAccounts.enable
• iam.serviceAccounts.delete
• iam.roles.list
• iam.roles.get
• iam.roles.create
• iam.roles.delete

After creation, the custom role is granted to the service account on the narrowest resource, such as one project, so the permission boundary applies only where the integration must operate. Policy auditing then retrieves the allow policy with getIamPolicy and remediates drift with setIamPolicy, which keeps deployed access aligned with least privilege.

2.3Creating and Attaching Service Accounts for Workloads

Creating and attaching service accounts for workloads is the ordered sequence that separates creation, authorization, and use of a least-privilege workload identity. A least-privilege workload starts with a new user-managed service account rather than reuse of the Compute Engine default service account. The default service account may automatically receive the Editor role through the iam.automaticIamGrantsForDefaultServiceAccounts organization policy constraint, and organizations created after May 3, 2024 enforce that constraint by default.

1. Create the account: A creator with roles/iam.serviceAccountCreator and roles/resourcemanager.projectIamAdmin creates the service account and grants it only the resource roles it needs.
2. Authorize attachment: A principal that will attach the account receives roles/iam.serviceAccountUser on that specific service account, which is recommended over granting the role at the project level where the principal would gain use of all current and future accounts.
3. Attach to the resource: The virtual machine (VM) or other resource is created with --service-account set to the new account email, so requests from that resource flow to Google Cloud APIs under the service account identity.
4. Set the API scope: The VM is set to the cloud-platform scope https://www.googleapis.com/auth/cloud-platform, or Allow full access to all Cloud APIs in the console, so IAM roles become the single enforcement point.

This order matters because attachment depends on the account existing first, and API calls depend on both the IAM grant and the scope. Granting roles/iam.serviceAccountUser together with roles/compute.instanceAdmin.v1 additionally authorizes creating, reconfiguring, connecting to, and attaching disks to instances that run as that service account.

2.4How Access Scopes Interact with IAM Roles

How access scopes interact with IAM roles is a two-gate check that decides the effective permission for a request from a VM to a Google Cloud API. The request flows from the application on the VM to the API, and IAM checks the service account allow policy while the instance checks its scope. Both checks must allow the action, so a narrow scope can block an action that the IAM role would otherwise permit.

For example, if a service account holds roles/compute.instanceAdmin.v1, roles/storage.objectViewer, and roles/compute.networkAdmin, applications using that account cannot act outside those three roles even with a broad scope. Conversely, if the same VM is limited to the read-only scope https://www.googleapis.com/auth/devstorage.read_only but the account holds roles/storage.objectAdmin, calls from gcloud CLI and client libraries cannot manage Cloud Storage objects because the scope does not authorize writes. Other scopes follow the same pattern, including https://www.googleapis.com/auth/compute for full control of Compute Engine, https://www.googleapis.com/auth/compute.readonly for read-only Compute Engine access, and https://www.googleapis.com/auth/logging.write for log writes.

2.5Auditing and Rightsizing Service Account Access

Auditing and rightsizing service account access is the ongoing process that keeps least privilege true over time by finding unused bindings and abandoned accounts. IAM Recommender, part of Policy Intelligence, uses machine learning to analyze permission usage and produce REMOVE_ROLE recommendations and insights about unused permissions and unused service accounts. Administrators export recommendations to BigQuery with the Data Transfer Service, query for recommender = "google.iam.policy.Recommender", and apply rightsizing to the allow policies.

Lifecycle controls enforce the result by moving accounts between active, disabled, and deleted states in order. An account needed only during onboarding stays active, moves to disabled when access must stop immediately during offboarding or incident response, and moves to deleted only after it is confirmed unneeded. For existing projects with an over-privileged default account, use Policy Simulator to model the impact before replacing Editor with narrower roles.

Service account authentication and key management is the practice of giving non-human workloads a Google Cloud identity without creating long-lived secrets that can leak. A service account (opens in a new tab) is a special account used by an application or compute workload rather than a person, identified by a unique email such as name@project-id.iam.gserviceaccount.com. Service accounts have no password and cannot be used for browser sign-in, and they are both a principal that can be granted access to resources and a resource that belongs to a Google Cloud project. Because a compromised service account can be used for privilege escalation, spoofing, and hiding actions, secure authentication prioritizes short-lived credentials and federation over static service account keys.

3.1How Service Account Authentication Works

Service account authentication is how a workload proves it is allowed to act as a service account when it calls Google Cloud APIs. The most common pattern is an attached service account, where a service account is attached to the resource running the code so the service account becomes the resource's default identity. Any workload on that resource, such as an application on a Compute Engine VM instance, requests OAuth 2.0 access tokens and OpenID Connect (OIDC) ID tokens from the metadata server and presents those tokens to Google Cloud services. A single VM can have only one attached service account, but the same service account can be attached to multiple VMs, so a role change affects every VM that shares it.

A second pattern is short-lived credentials obtained on demand through impersonation or the Service Account Credentials API. In many cases these credentials are obtained automatically, such as attached service accounts and commands that use the gcloud flag --impersonate-service-account, so teams do not create or store secrets themselves. A third pattern is a service account key, where the workload uses a stored private key to sign a JSON Web Token (JWT) and exchanges the JWT for an access token. Service account keys work in any environment, but they are a security risk if not managed correctly because anyone who copies the private key can authenticate as the service account until the key is deleted.

3.2Choosing an Authentication Method

Choosing an authentication method means selecting the credential path used by Application Default Credentials (ADC) in the Google Cloud CLI, Cloud Client Libraries, Terraform, or REST requests. IAM guidance recommends avoiding service account keys whenever possible and following a decision order that keeps trust boundaries explicit. Local development stays tied to a human identity, Google Cloud workloads inherit identity from their attached resource, and external workloads federate an existing identity provider identity rather than copying a static key.

1. Single-user development environment: If code runs on a workstation, Cloud Shell, or virtual desktop, check whether a service account is required; if not, authenticate with user credentials, and if so, impersonate a service account with user credentials.
2. Workload location: If code does not run in a single-user environment, check whether it runs in Google Cloud; if not, evaluate federation for external workloads.
3. Containers in Google Cloud: If code runs in Google Cloud on Google Kubernetes Engine (GKE), use Workload Identity Federation for GKE to attach service accounts to Kubernetes pods; if not, attach a service account to the resource.
4. External identity provider: If code runs outside Google Cloud, check whether the workload authenticates with an external identity provider (IdP) that supports Workload Identity Federation (opens in a new tab); if yes, configure Workload Identity Federation for on-premises or other clouds, and if no, create a service account key as a last resort.

3.3Comparing Workload Identity Options and Static Keys

Workload identity options let workloads use identities they already have instead of storing service account private keys. Workload Identity Federation lets workloads access most Google Cloud services by using an identity provided by an IdP, and those workloads can run on Google Cloud, GKE, or other platforms such as AWS, Azure, and GitHub. Workload Identity Federation for GKE grants IAM access directly to GKE clusters and Kubernetes service accounts without IAM service account impersonation, while federation for on-premises or another cloud provider is the preferred method for setting up ADC outside Google Cloud.

Static keys invert the security tradeoff because the credential travels with the code and can be copied, committed, or leaked, while federated and attached identities keep the long-term secret in IAM and expose only short-lived tokens to the workload.

3.4Using Short-Lived Credentials for Temporary Access

Short-lived credentials are temporary OAuth 2.0 access tokens and OIDC ID tokens that grant a service account's permissions for a limited time. The Service Account Credentials API supports temporary privilege elevation by letting a supervisor identity mint tokens for narrower service accounts only when they are needed. This design avoids granting one service account permanent access to every resource the application might ever need.

A token-broker implementation follows this order:

1. Create dedicated service accounts: Create a separate service account for each part of the application or use case and grant each service account access to only the resources it needs.
2. Create a supervisor service account: Create another service account that acts as the supervisor and grant it the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) on the other service accounts.
3. Isolate the broker: Split the application so that only one token-broker component is allowed to use the supervisor service account.
4. Issue tokens on demand: Have the token broker request short-lived credentials for the narrower service accounts and pass those tokens to the other parts of the application.

The workflow depends on IAM policy in both directions: the supervisor depends on iam.serviceAccounts.getAccessToken permission on each target service account, and each target service account depends on its own narrow role grants to reach only its required buckets, instances, or APIs.

3.5Managing Service Account Keys Safely

Service account key management is the control of creation, storage, rotation, and deletion for static service account private keys. Keys should be used only when there is no viable alternative, because a leaked key lets an attacker authenticate as the service account from anywhere and may obscure who performed an action in Cloud Audit Logs. For local development, impersonating a service account with user credentials is safer than downloading a key to test permissions.

When keys cannot be avoided, reduce creation and blast radius with these controls:

• Do not let users create or upload service account keys unless no federated or impersonated path can work.
• Do not use automatic role grants for default service accounts, and do not grant Owner, Editor, or Viewer in production; grant a predefined role or custom role that meets the need.
• Manage access for each service account individually rather than granting token-creator or user access at the Google Cloud project or folder level, where one grant can expose every service account in the project.
• Identify unused service accounts, disable them before deleting them, and treat service accounts as resources tied to a VM, application, or environment rather than as standalone user accounts.

On Compute Engine, authorization also depends on access scopes in addition to IAM roles, so key and token hygiene alone does not determine access. Both the roles granted to the attached service account and the access scopes set on the instance must allow access before an application on the instance can reach a resource.

Key Facts

• The Google Cloud resource hierarchy flows from organization to folder to project to service-specific resource, and an allow policy attached to an ancestor is inherited by all descendants below it.
• The effective allow policy for a resource is the union of its own allow policy and the allow policies of all its ancestors.
• Service accounts for production workloads should receive predefined roles or custom roles on the narrowest project or resource, not basic Owner, Editor, or Viewer roles at the organization or folder level.
• A request from a Compute Engine VM to a Google Cloud API must pass both the service account IAM role check and the instance access scope check.
• Attached service accounts, Workload Identity Federation for GKE, and Workload Identity Federation for external workloads are preferred over static service account keys, which should be created only as a last resort.