Cloud Workload Identity Guide: AWS, Azure and Google Cloud

Every cloud workload needs an identity, and the safest one is an identity that never hands you a key. Virtual machines, functions, containers and CI/CD jobs all call cloud APIs. AWS, Microsoft Azure and Google Cloud each let hosted workloads obtain short-lived credentials from the platform, and offer federation for workloads that run elsewhere. This guide explains how cloud workload identity works on each platform, how keyless CI/CD is built, where trust configurations go wrong, and how to govern the result.

Key takeaways

The core risk in cloud workload identity is the long-lived secret that often stands in for the identity: AWS access keys, Azure client secrets and Google service account keys.
All three clouds can issue short-lived credentials to workloads they host: IAM roles with AWS STS, Azure managed identities, and attached Google service accounts. Use them by default.
For workloads outside the cloud, workload identity federation exchanges a signed token from the workload’s own platform for short-lived cloud credentials.
With federation, the trust condition becomes the security control. An overbroad subject condition lets other repositories or branches assume your role.
Governance still matters: inventory every workload identity, assign owners, remove unused permissions, and alert on any use of long-lived keys.

What a cloud workload identity is

When a workload (an application, function, container task or pipeline step) calls a cloud API, the provider needs to know which principal is calling. That principal is the workload’s identity, and it is one of the most common types of non-human identity in any organisation.

Each cloud names the parts differently, but the pattern is the same:

An identity object that holds permissions: an IAM role on AWS, a managed identity or application service principal in Microsoft Entra ID, a service account on Google Cloud.
A credential that proves the workload may act as that identity: ideally a short-lived platform-issued token, too often a static key.
A trust relationship that says who may obtain credentials: a trust policy, a federated identity credential, an IAM binding.

Why static keys are the core risk

IAM user access keys, Entra ID client secrets and Google service account keys share the same weaknesses. They are bearer credentials that work from anywhere until someone revokes them. They get copied into .env files, CI/CD variables and images, which is how secret sprawl starts. And the challenges of rotating NHI credentials mean many are never rotated.

The incident record is consistent. The extortion campaign against AWS environments began with IAM keys found in exposed .env files, which the attackers then used to create new roles with administrator access. In the TruffleNet campaign, stolen AWS access keys were checked with GetCallerIdentity and then used to abuse Amazon SES for business email compromise. The Emerald Whale operation harvested cloud credentials from exposed Git configuration files.

The OWASP Non-Human Identities Top 10 covers these themes in NHI2:2025 Secret Leakage, NHI6:2025 Insecure Cloud Deployment Configurations and NHI7:2025 Long-Lived Secrets. Our NHI Authentication Guide compares machine authentication methods more widely.

AWS: IAM roles and temporary credentials

IAM users with access keys versus IAM roles

An IAM user can hold long-term access keys. An IAM role has no long-term credentials: a trusted principal assumes it and AWS Security Token Service (STS) returns temporary credentials that include a session token. The AWS IAM security best practices recommend temporary credentials over long-term access keys wherever possible. Temporary security credentials can be configured to last from a few minutes to several hours, and expired credentials are simply rejected, so nothing needs rotating by hand.

Roles for compute services

EC2: an instance profile passes one IAM role to an instance, and applications fetch its temporary credentials from the Instance Metadata Service. Require IMDSv2, whose session tokens add defence in depth against server-side request forgery and open proxies.
Lambda: each function has an execution role that Lambda assumes automatically on invocation.
ECS: distinguish the task IAM role (used by your application code) from the task execution role (used by the ECS and Fargate agents to pull images). Keep application permissions off the execution role.
EKS: pods can map Kubernetes service accounts to IAM roles. The Kubernetes NHI Security Guide covers pod identity on managed clusters.

Trust policies and the confused deputy problem

Every role has a trust policy that defines who may assume it. When a third party assumes a role in your account, the confused deputy problem arises because role ARNs are not secret: another customer of that provider could supply your ARN and have the provider use it. The defence is an sts:ExternalId condition in the trust policy, with a unique per-customer value. For AWS services acting on your resources, add aws:SourceArn or aws:SourceAccount conditions to resource policies.

Workloads outside AWS

IAM Roles Anywhere: workloads outside AWS present an X.509 certificate from your certificate authority, registered as a trust anchor; a profile specifies which roles may be assumed. See the IAM Roles Anywhere user guide. Protect the private key: it is now the credential.
OIDC federation: an IAM OIDC identity provider lets workloads exchange a JWT from a trusted issuer for role credentials through AssumeRoleWithWebIdentity. This is how CI/CD systems and external Kubernetes clusters reach AWS without stored keys.

Azure: managed identities, service principals and federation

Managed identities

Managed identities for Azure resources let a workload obtain Microsoft Entra tokens without handling any credential; the credentials are not even accessible to you. There are two types:

System-assigned: created as part of a single Azure resource and deleted with it. It cannot be shared, which keeps audit trails precise.
User-assigned: a standalone Azure resource with its own lifecycle that can be attached to several resources. Microsoft recommends it for most scenarios, but sharing it means several workloads hold the same permissions.

Two behaviours catch teams out. Anyone who can run code on a resource can use its managed identity’s permissions. And role assignments are not deleted automatically when a managed identity is deleted, so orphaned assignments must be cleaned up.

App registrations, service principals and their credentials

An application object is the global definition of an app in its home tenant; a service principal is its local instance in each tenant where it is used. Managed identities are a special service principal type with no application object. Workloads that cannot use a managed identity usually authenticate as an app registration’s service principal.

Microsoft’s security best practices for application properties set an order of preference: managed identity; then a federated identity credential for workloads on other platforms; then a certificate from a trusted CA, stored in a key vault; and never client secrets, which are often mismanaged and easily compromised. Application management policies can limit secret lifetimes or block secrets entirely. Keep application owners few and reviewed, because an owner can add credentials.

This is a real attack path. In the Storm-2949 Azure intrusion, the attackers tried to add credentials to a service principal to move laterally, which the write-up identifies as high-value pivot points. Role design matters too: the Key Vault Contributor exposure showed a management role able to grant itself access to the secrets inside.

Workload identity federation in Microsoft Entra ID

Workload identity federation lets a user-assigned managed identity or an app registration trust tokens from an external identity provider such as GitHub, Google Cloud, AWS or a Kubernetes cluster. A federated identity credential names the trusted issuer, subject and audience; Entra ID checks the external token against it and returns an access token. Note that:

Issuer, subject and audience must match the incoming token exactly and case-sensitively. Wildcards are not supported in any federated identity credential property.
A mistyped subject is accepted when you create the credential; the failure only shows up when the token exchange is rejected.

Google Cloud: service accounts and Workload Identity Federation

Service accounts and why to avoid keys

On Google Cloud, a service account is the workload identity. The default Compute Engine and App Engine service accounts are granted the Editor role on the project when created, and Google recommends disabling automatic IAM grants for default service accounts through organisation policy.

A service account key is a long-lived private key that lets anyone holding it act as the service account. Google’s best practices for managing service account keys recommend a more secure alternative wherever possible. The iam.disableServiceAccountKeyCreation and iam.disableServiceAccountKeyUpload constraints block new keys, and Google enforces them by default for newer organisations. Google Cloud can also be configured to disable keys it detects as publicly exposed.

Attached service accounts

For code running on Google Cloud, attach a service account to the resource; client libraries then authenticate as it with no key file. Attaching requires iam.serviceAccounts.actAs, which is in the Service Account User role. For most resource types other than Compute Engine, the attached service account cannot be changed after creation.

Service account impersonation

A principal with iam.serviceAccounts.getAccessToken (included in the Service Account Token Creator role) can impersonate a service account and receive short-lived credentials for it. This replaces downloaded keys for local development and federated access, and it is also a privilege escalation path: Google’s best practices for using service accounts securely warn against granting roles that contain actAs or token-creation permissions broadly, recommend single-purpose service accounts rather than shared or default ones, and advise disabling an account before deleting it.

Workload Identity Federation: pools and providers

Workload Identity Federation lets external workloads access Google Cloud without keys. A workload identity pool groups external identities, and Google recommends a separate pool for each non-Google Cloud environment. A provider describes the trusted identity provider: AWS, Microsoft Entra ID, OIDC issuers such as GitHub, SAML and others. Attribute mappings translate token claims into Google attributes, and attribute conditions (written in Common Expression Language) decide which tokens are accepted at all. Federated identities can be granted roles directly or impersonate a service account.

Keyless CI/CD with GitHub Actions OIDC

CI/CD pipelines are where cloud keys are most exposed. The tj-actions supply chain attack dumped CI/CD secrets, including AWS credentials, into build logs. OIDC removes the stored key: GitHub issues each job a signed JWT, the cloud validates it against a trust configuration, and the job receives short-lived credentials (see GitHub’s OIDC documentation).

How it is wired on each cloud

Workflow: the job needs permissions: id-token: write, which lets it request an OIDC token and grants no other write access.
AWS: create an IAM OIDC identity provider for https://token.actions.githubusercontent.com and a role whose trust policy checks token.actions.githubusercontent.com:aud equals sts.amazonaws.com and constrains token.actions.githubusercontent.com:sub.
Azure: add a federated identity credential to an app registration or user-assigned managed identity with GitHub’s issuer and an exact subject.
Google Cloud: create a pool and an OIDC provider for GitHub, map google.subject to assertion.sub, add an attribute condition, and grant roles to the matching principals or let them impersonate a service account.

Scoping trust conditions

The token’s claims describe exactly which workflow is calling: sub, repository, repository_owner, ref, environment, job_workflow_ref and more. The sub claim combines several of these, for example repo:my-org/my-repo:ref:refs/heads/main for a branch or repo:my-org/my-repo:environment:prod for a job that targets a deployment environment. GitHub is moving new repositories to a default subject format that includes numeric owner and repository IDs, so check what your repositories emit.

Because GitHub uses one issuer for every customer, a condition that is too loose trusts code you do not control. The platforms now push back:

When GitHub’s provider is trusted, AWS IAM rejects a trust policy that lacks a token.actions.githubusercontent.com:sub condition or sets it only to a wildcard.
Google’s deployment pipeline guidance requires an attribute condition restricting tokens to your GitHub organisation, and recommends numeric fields such as repository_id and repository_owner_id over names, which can be reused after deletion.
Entra ID does not allow wildcards in federated credentials, so each subject is an explicit entry.

Passing the platform check is not the same as being well scoped. repo:my-org/* still lets every repository in the organisation assume a production role. Prefer environment-based subjects for deployment roles, so the GitHub environment’s protection rules (required approval, restrictions on which branches can deploy) gate who can obtain production credentials. Give pull request and build jobs separate, read-only roles. OWASP lists unrestricted subject claims under NHI6:2025 Insecure Cloud Deployment Configurations.

Cross-cloud and multi-cloud access

The same features let clouds trust each other, so no workload needs a stored key for another cloud:

AWS to Azure or Google Cloud: AWS outbound identity federation lets AWS workloads request short-lived, signed JWTs from STS through GetWebIdentityToken, which external services can verify. IAM policies control audiences and duration. Google Workload Identity Federation also supports AWS as a provider type.
Google Cloud or AWS to Azure: Entra ID federated identity credentials accept tokens from Google Cloud and AWS workloads.
Azure to Google Cloud or AWS: a managed identity’s Entra token can be presented to a Google provider for Microsoft Entra ID, or to an AWS IAM OIDC identity provider that trusts your Entra ID tenant as an issuer.
Everywhere: for one portable identity across clouds and data centres, SPIFFE issues attested workload identities, and Microsoft lists SPIFFE among its federation scenarios. Our guide to SPIFFE and SPIRE explains the model.

Treat every cross-cloud trust as a new entry point. Pin the issuer to the specific account, tenant or project, pin the subject to the specific workload identity, and set the audience to a value only your configuration uses.

AWS, Azure and Google Cloud compared

Concept	AWS	Microsoft Azure / Entra ID	Google Cloud
Workload identity primitive	IAM role	Managed identity (system- or user-assigned); app registration and service principal	Service account
Short-lived credential for hosted workloads	STS temporary credentials via instance profile, Lambda execution role, ECS task role	Entra access token obtained by the managed identity	Short-lived token for the attached service account
Delegation between identities	`sts:AssumeRole`, with `sts:ExternalId` for third parties	Role assignments to the service principal; app owners control who can add credentials	Service account impersonation (`getAccessToken`)
External federation feature	IAM OIDC and SAML providers (`AssumeRoleWithWebIdentity`), IAM Roles Anywhere for X.509	Workload identity federation with federated identity credentials	Workload Identity Federation (pools and providers)
Trust condition you must scope	Trust policy conditions on `aud` and `sub`	Exact issuer, subject and audience match	Attribute conditions and principal bindings
Long-lived secret to avoid	IAM user access keys	Client secrets (then certificates)	Service account keys
Built-in control for keys	IAM Access Analyzer unused access key findings (detective)	Application management policies to restrict secrets	Organisation policy constraints that disable key creation and upload

Common misconfigurations

Keys left behind after migration. The workload moved to a role or managed identity, but the old key still works.
Overbroad federation subjects. Trusting a whole organisation or any branch, or skipping the audience check.
Shared identities. One identity used by many unrelated workloads, blurring audit trails and aggregating permissions (OWASP NHI9:2025 NHI Reuse).
Default service accounts with Editor. Workloads running with an inherited project-wide basic role.
Third-party roles without an external ID, leaving the confused deputy door open.
IMDSv1 still accepted, letting server-side request forgery retrieve role credentials.
Over-permissive delegation rights. Broad grants of Service Account User or Token Creator on Google Cloud, iam:PassRole on AWS, or app ownership on Entra ID, each of which lets one identity become another.
Overpowered long-lived tokens outside IAM. The Microsoft SAS token exposure involved a storage token with broad permissions and no expiry: storage-level tokens need the same scrutiny as identity credentials.
Excess permissions on stolen identities. Once attackers held valid credentials, the crypto-mining campaign against AWS accounts ran mining workloads on EC2 and ECS, and the Codefinger ransomware used compromised credentials to re-encrypt S3 data with attacker-held keys. Least privilege (OWASP NHI5:2025 Overprivileged NHI) limits the damage.

A maturity path: from long-lived keys to federation

Discover. List every IAM user with access keys, every app registration with secrets or certificates, and every service account key. The NHI lifecycle management guide covers discovery and ownership.
Contain. Move remaining keys into a secrets manager, scope them tightly and set expiry where supported.
Use native identities. Move hosted workloads to IAM roles, managed identities and attached service accounts, then delete the old keys.
Federate the rest. Move CI/CD, other clouds, Kubernetes and on-premises workloads to federation or IAM Roles Anywhere.
Prevent regression. Enforce the Google key-creation constraints, restrict Entra client secrets with application management policies, and alert on new AWS access keys.
Standardise. Use one identity pattern per workload type across clouds, with trust conditions defined as reviewed code.

This mirrors our section on static versus dynamic secrets, and the Machine-to-Machine Identity Maturity Model sets out a comparable progression.

Governance: inventory, ownership and least privilege

Inventory and ownership

Keep one inventory of workload identities across all three clouds, with the workloads that use them and the trust relationships that let external systems in. Every entry needs an accountable owner and a purpose; ownerless identities are the ones nobody notices being misused, and nobody dares delete. Fold them into your wider identity governance; IAM and IGA Basics explains how access reviews apply.

Least privilege and unused permission review

AWS: IAM last accessed information and IAM Access Analyzer unused access findings identify unused roles, unused access keys and unused service- and action-level permissions.
Azure: review role assignments on managed identities and service principals, remove orphaned assignments, and check credential expiry and last use on app registrations.
Google Cloud: Activity Analyzer shows when service accounts and keys last authenticated, and role recommendations suggest permissions to remove.

Permission to create keys, add credentials, pass roles or impersonate is permission to become the target, so review it as privileged access.

Detecting key usage

On AWS, CloudTrail records the access key ID used for each call; long-term key IDs begin with AKIA and temporary ones with ASIA, so alert on AKIA activity in role-only accounts and on CreateAccessKey events.
On Entra ID, monitor service principal sign-in logs and managed identity sign-in logs, and alert when a credential is added to an application or service principal.
On Google Cloud, enable data access logs for the IAM and Security Token Service APIs, and alert on service account key creation.

Practitioner checklist

Inventory every workload identity and long-lived credential across all three clouds, each with an owner.
Run hosted workloads on IAM roles, managed identities or attached service accounts; delete the keys they replace.
Require IMDSv2 on EC2 and keep application permissions off ECS task execution roles.
Add sts:ExternalId to every third-party role trust policy and source conditions to service-principal resource policies.
Prefer managed identities, then federated credentials, then certificates on Entra ID; block client secrets with application management policies.
Enforce Google Cloud constraints that disable service account key creation and upload, and turn off automatic Editor grants for default service accounts.
Move CI/CD to OIDC; pin aud, and pin sub to a specific repository and environment, never a whole organisation.
Give build, test and deploy jobs separate identities with separate permissions.
Restrict who can create keys, add credentials, pass roles or impersonate service accounts.
Review unused identities and permissions on a fixed schedule and remove them.
Alert on creation or use of long-lived keys and on new federation trusts.

Standards and references

Related NHI Mgmt Group resources: The Ultimate Guide to Non-Human Identities · Kubernetes NHI Security Guide · Top 10 NHI Issues · NHI Breaches Report