Least Privilege Access for Cloud Workloads

Resource-Level IAM Scoping and Policy Restriction is the practice of attaching an IAM allow policy to the lowest-level resource that needs it, such as a single Cloud Storage bucket or Pub/Sub topic. A policy attached at a higher level reaches everything below it, while a policy attached at the resource level reaches only that resource. This tight scoping applies least privilege to cloud-native applications and prevents lateral movement if one identity is compromised.

1.1Resource Hierarchy and Policy Attachment Point

The Google Cloud resource hierarchy defines where an Identity and Access Management (IAM) (opens in a new tab) allow policy can attach and how far its access reaches. The Organization resource sits at the top and provides central visibility and control over every resource in the organization. An organization contains folders, folders group related projects, and projects contain service resources such as Compute Engine virtual machines (VMs), Pub/Sub topics, Cloud Storage buckets, and Cloud VPN endpoints.

An IAM allow policy applies to the resource where the policy is attached. A policy attached to a project grants access across all service resources inside that project, while a policy attached to a specific bucket or topic grants access only to that bucket or topic. Choosing the resource-level attachment keeps the trust boundary tight, so a compromised service account that can read one bucket cannot move sideways to read other buckets, topics, or VMs in the same project.

1.2Principals, Roles, and Allow Policies

The IAM access model decides whether a request from a principal to a resource is allowed. The IAM service binds identities to permissions at a chosen resource, and the request flows from the principal to the resource where the attached policy is checked. A principal cannot perform any action that its bound roles do not permit on that resource.

• Principal: The identity making the request, such as a Google Account for a user, a service account for an application, a Google Group, or a Google Workspace or Cloud Identity account.
• Role: A collection of permissions, such as predefined job-function roles or custom roles created from predefined roles.
• Permission: A single allowed operation on a resource, such as reading a bucket or publishing to a topic.
• IAM allow policy: The binding that attaches a set of principals to a role on a specific resource.

Using job-function roles keeps each binding limited to what the job needs. Creating custom roles from predefined roles lets teams remove unneeded permissions without starting from broad access.

1.3Granular Controls That Limit Blast Radius

Granular controls in Google Cloud restrict what a scoped policy can reach even after access is granted. Tags in Resource Manager add annotations to resources so policies can conditionally allow or deny access based on whether a resource has a specific tag. Tag-based conditions provide fine-grained control across the hierarchy without creating a separate project for every isolation need.

Two organization-wide guardrails reinforce resource-level scoping. The constraints/iam.automaticIamGrantsForDefaultServiceAccounts constraint disables automatic grants of the Editor role (roles/editor) to default service accounts, because that project-wide role would let an attacker who compromises one component control the entire project. The constraints/iam.allowedPolicyMemberDomains constraint for domain restricted sharing limits which customer IDs can be added to IAM policies, so only trusted, managed corporate identities receive access. Principal access boundary (PAB) policies add another limit on the principal side. A PAB policy attached through iam.googleapis.com/PrincipalAccessBoundaryPolicy caps the maximum access a principal can use, which reduces the extent of an attack with a compromised identity and helps block phishing and data exfiltration.

Service Account Management and Custom Role Implementation is the practice of replacing broad default identities with dedicated, minimally privileged identities for cloud-native applications. A workload authenticates as a service account (opens in a new tab), and IAM controls what that account can do through roles. Least privilege means each application gets only the permissions it needs and nothing more.

2.1What Service Accounts Are

A service account is a non-human identity for workloads, such as a custom application that accesses resources without end-user involvement. Service accounts have no password and cannot be used for browser sign-in, and each service account belongs to a Google Cloud project and is identified by a unique email address. A service account is both a principal and a resource: as a principal it can be granted access to resources like a Cloud Storage bucket, and as a resource it can be accessed and impersonated by other principals like a user or group.

Because of this dual nature, a compromised service account creates two kinds of harm: harm done by the account and harm done to the account. Common abuse patterns include:

• Privilege escalation: a bad actor impersonates the service account to gain access to resources they could not otherwise reach.
• Spoofing: a bad actor uses service account impersonation to obscure their identity.
• Non-repudiation failure: a bad actor carries out operations as the service account so actions cannot be traced back to them.
• Information disclosure: a bad actor learns about infrastructure or software from the existence or name of service accounts.

Limiting privileges reduces harm when a service account acts as a principal, while protecting impersonation, keys, and access reduces harm when it acts as a resource.

2.2Risks of Default Service Accounts and Broad Access

Risks of default service accounts and broad access come from automatic identities combined with primitive roles. Default service accounts are created automatically when certain Google Cloud APIs are first enabled, and depending on organization policy they may automatically receive the Editor role (roles/editor) on the project. That role allows reading and modifying all resources in that project, and the grant exists for convenience and is not essential for services to work.

If one part of the system is compromised, an Editor-granted default account lets an attacker move across the entire project. Access scopes on Compute Engine VMs do not fix this, because scopes are coarse-grained. For example, a storage read-only scope can limit calls to read-only operations but cannot limit access to specific buckets, so scopes cannot replace fine-grained allow policies. To prevent automatic over-granting, enforce the iam.automaticIamGrantsForDefaultServiceAccounts organization policy constraint on the organization or folder.

2.3Creating Single-Purpose User-Managed Service Accounts

Single-purpose user-managed service accounts are dedicated identities that belong to one task, application, or resource, such as one VM instance or one integration. Creating a separate service account for each task makes access easier to manage and makes audit logs easier to trace to a specific workload. Grant each account only the permissions needed for its intended task, and attach the account directly to the compute resource so code obtains short-lived tokens from the metadata server instead of using long-lived keys.

Manage service accounts as resources tied to the lifecycle of their workload, not as standalone users. Follow a clear naming and documentation convention, and choose generic names like deployer instead of revealing software like jenkins, because allow policies are widely readable and email addresses can disclose project IDs and tooling. When an account is no longer needed, first move it to disabled and delete it only after a waiting period; disabling preserves IAM bindings so the account can be re-enabled safely, while deleting removes the identity. Deleted default service accounts cannot be recreated, so leave an unused default account disabled if future use is possible.

2.4Implementing Predefined and Custom Roles for Least Privilege

IAM roles for service accounts divide into broad defaults and tailored least-privilege options. Predefined roles bundle permissions by job function, while custom roles define fine-grained permissions tailored to one application requirement. For example, a custom role can allow a service account to read and write data in a Cloud Storage bucket but not delete it.

Replace an existing Editor grant by first using Policy Simulator to see the impact of the change, then granting the needed predefined or custom roles and revoking Editor. Avoid managing impersonation rights at the project or folder level, because granting Service Account Token Creator at the project level lets a user impersonate every service account in that project and inherit access to resources outside it.

2.5Keeping Privileges Right-Sized Over Time

Right-sizing is the ongoing process of removing unused permissions and narrowing short-term access so service accounts stay at least privilege as applications change. The IAM recommender, part of Policy Intelligence, uses machine learning to recommend removal of unused roles and to identify abandoned service accounts. Activity Analyzer shows recent authentication activity to confirm whether a shared account is still used, and the Service Account Credentials API lets a supervisor service account with the Service Account Token Creator role issue short-lived access tokens for dedicated workload accounts.

Additional controls further reduce the blast radius around privileged accounts:

• Do not rely on access scopes: create a dedicated service account with fine-grained allow policies instead of depending on coarse VM scopes.
• Avoid domain-wide delegation: delegation lets a service account impersonate any user in a Cloud Identity or Google Workspace account, including super-admins, so use direct service account access or OAuth consent flow instead.
• Use Credential Access Boundaries: downscope access tokens so a token carries fewer permissions than the underlying service account.
• Use role recommendations and lateral-movement insights: detect unused permissions and paths an attacker could use to move between accounts.
• Limit compute exposure: restrict shell access with OS Login and Identity-Aware Proxy TCP forwarding, limit metadata-server access to selected users and processes with host firewalls, and do not run code from less-protected sources on resources with a privileged account attached.

Workload Identity and Ephemeral Credentialing is the practice of giving programmatic workloads a Google Cloud identity that uses short-lived tokens instead of long-lived keys. A workload is programmatic access by an application, while workforce is access by a human user. Workload Identity Federation (opens in a new tab) exchanges an external or Kubernetes identity for short-lived Google credentials, so each service gets only the permissions it needs and the attack surface stays small.

3.1Tokens and Short-Lived Access

A token is a digital object that proves a caller exchanged proper credentials for temporary access. The token carries the identity of the principal making the request and the type of access that principal is authorized for, like a hotel key that opens a guest room and elevator but not other rooms or service areas. With the exception of API keys, Google APIs do not accept credentials directly, so an application must acquire or generate a token and present that token to the API.

Service account impersonation and federation both follow this pattern: the workload presents its own identity to an authority, receives a short-lived token, and traffic flows from the workload to the Google Cloud API with that token. Because the token expires quickly, a leaked token is useful to an attacker for only a short time.

3.2Service Account Authentication Choices

Service account authentication choices are the methods an application can use to act as a service account, ordered from most secure to least secure. Production code running on Google Cloud should use the most secure option that fits.

1. Attach a user-managed service account to the resource and use Application Default Credentials (ADC) to authenticate: The compute resource holds the identity, code running on that resource requests tokens through ADC, and no key file is stored with the application.
2. Use a service account to impersonate another service account: The original service account temporarily gains extra privileges to perform the required access, then returns to its lower-privilege state without permanently acquiring more privilege.
3. Use Workload Identity Federation to authenticate workloads that run on-premises or on a different cloud provider: Tokens issued by the existing external identity provider are exchanged for Google credentials, so no Google key is created or stored outside Google Cloud.
4. Use the default service account: The default service account is highly privileged by default, which violates the principle of least privilege and is not recommended.
5. Use a service account key: The private key is long-lived, must be stored and rotated by the owner, and creates a security risk if leaked, so choose a more secure alternative whenever possible.

3.3Giving GKE Pods Access to Google Cloud Resources

Giving Google Kubernetes Engine (GKE) Pods access to Google Cloud resources means connecting a Kubernetes identity to a Google Cloud identity under least privilege. Three options differ in how the Pod obtains its identity and how broadly that identity is shared.

Because the node service account is shared by every Pod on the node, a compromise of one Pod can expose the credentials used by all Pods on that node. Federation preserves least privilege because the permission boundary follows the Kubernetes service account to a single IAM service account, and revoking that mapping affects only the paired application.

3.4Authenticating Workloads on Google Cloud and Outside Google Cloud

Authenticating a workload on Google Cloud depends on the service account attached to the compute resource where the code runs, such as a Compute Engine VM instance. This attached-identity approach is the preferred method for code running on a Google Cloud compute resource, and Application Default Credentials (ADC) lets client libraries obtain tokens from that attached identity automatically. For most services the service account must be attached when the resource is created and cannot be added or replaced later, while Compute Engine allows a service account to be attached to a VM instance at any time.

Authenticating a workload from on-premises or another cloud provider depends on Workload Identity Federation, where the workload exchanges its external token through the Secure Token Service (STS) for short-lived Google credentials. The workload depends on STS to validate the external token and return Google credentials, so no long-lived Google key ever leaves Google Cloud.

3.5Reducing Stored Secrets and Controlling Token Exchange

Workload Identity Federation reduces the number of stored secrets by reusing tokens an application already has. An application that integrates with an OpenID or SAML identity provider often stores a client secret to authenticate to that provider, and giving that application Google Cloud access leaves two choices: create a service account key and store it alongside the client secret, or exchange tokens from the existing provider for Google credentials through federation. The first path requires managing and rotating two secrets, while the second path requires only one, which simplifies rotation and improves security.

When token exchange must stay in a specific region for data residency, the workload depends on a regional STS endpoint such as https://sts.REGION.rep.googleapis.com instead of the global https://sts.googleapis.com endpoint. The regional endpoint keeps the exchange inside that region while still returning short-lived credentials for Google Cloud APIs.

3.6Protecting Workload Identity Pools From Spoofing

A workload identity pool is a view that surfaces identities from external identity providers so they can be used as IAM principals, not a directory that contains user accounts like Cloud Identity. Because federation uses claims-based identities, two tokens from the same issuer that map to the same google.subject value are treated as the same user. Ambiguous mappings can let several external identities map to one principal or one identity map to many principals, which enables spoofing, especially with multi-tenant providers like GitHub that share one issuer URL across all tenants.

• Require attribute conditions that restrict which tenant, organization, or repository can federate, especially for multi-tenant providers.
• Use a dedicated project to manage pools and providers, and use organization policy constraints to disable pool provider creation in other projects.
• Use one provider per pool and avoid federating with the same identity provider twice to prevent subject collisions.
• Use the pool provider URL as the audience and protect the OIDC metadata endpoint of the identity provider.
• Map only immutable, non-reusable, stable, and authoritative attributes, and prevent later modification of attribute mappings.

Least-privileged services depend on three linked controls: resource-level IAM policies limit where access applies, single-purpose service accounts with tailored roles limit what access exists, and Workload Identity Federation with short-lived tokens limits how long access lasts. A tight resource attachment contains a compromise, a dedicated identity keeps that containment tied to one workload, and ephemeral credentialing removes the long-lived keys that would let an attacker reuse stolen access.

Key Facts

• An IAM allow policy attached to a specific Cloud Storage bucket or Pub/Sub topic grants access only to that resource, while a policy attached to the containing project grants access to every resource in that project.
• The constraints/iam.automaticIamGrantsForDefaultServiceAccounts organization policy constraint blocks automatic grants of the Editor role to default service accounts.
• A service account is both a principal that can be granted access to resources and a resource that can be impersonated by other principals.
• Workload Identity Federation for GKE lets Pods that run as a Kubernetes service account receive the permissions of a mapped IAM service account without using node credentials or JSON keys.
• Workload Identity Federation exchanges an external token through the Secure Token Service for short-lived Google credentials so no long-lived Google key is stored outside Google Cloud.