Workload Identity: The Pattern That Removes Long-Lived Credentials

Workload identity lets services assume IAM roles without static credentials. The pattern, the providers, and the migration.

AWS: IRSA

Workload identity is the discipline of giving workloads (services, pods, jobs) their own cryptographic identity rather than sharing static credentials. With workload identity, each workload authenticates with its own short-lived token; permissions follow the workload's identity. The pattern eliminates static credentials in code or environment variables and provides per-workload audit trails.

What AWS IRSA provides:

• IAM Roles for Service Accounts.: IRSA is AWS's workload identity for EKS. Each Kubernetes ServiceAccount can be associated with an IAM role; pods using that ServiceAccount inherit the role's permissions.
• K8s service accounts assume IAM roles.: The mechanism uses OIDC: the EKS cluster issues tokens for ServiceAccounts; AWS STS validates the tokens and issues IAM session credentials. The flow is automatic; the pod receives credentials transparently.
• Tokens scoped per pod.: The credentials a pod receives are specific to that pod's ServiceAccount. Two pods in the same node with different ServiceAccounts get different credentials. The isolation prevents privilege escalation across pods.
• Rotated automatically.: The OIDC tokens are short-lived (typically an hour); the AWS sessions are similarly short. Rotation is automatic; the pod's SDK refreshes credentials seamlessly. Static long-lived credentials are eliminated.
• Per-workload audit trails.: CloudTrail records each API call with the assumed role identity. Investigators can trace activity to specific workloads; per-workload accountability is real.

IRSA is the AWS standard for workload identity in Kubernetes. It has become the default pattern for new EKS deployments.

GCP: Workload Identity

GCP offers an analogous mechanism. The implementation differs from AWS but the value proposition is the same: each workload has its own identity; permissions follow identity; static credentials are eliminated.

• Similar mechanism for GCP.: GCP Workload Identity binds Kubernetes ServiceAccounts to GCP service accounts. The binding allows pods to authenticate with GCP services using their ServiceAccount's identity.
• K8s service accounts map to GCP service accounts.: Each Kubernetes ServiceAccount can be mapped to a GCP service account. The mapping is explicit; the GCP IAM permissions follow the GCP service account; the Kubernetes ServiceAccount inherits via the binding.
• Token-based authentication.: The mechanism uses GCP-native OAuth tokens. Pods receive tokens that authenticate them to GCP APIs; the tokens are short-lived and refreshed automatically.
• Cross-cloud workload identity.: Workload Identity Federation extends the pattern: workloads in one cloud can authenticate to GCP using their cloud's identity. AWS workloads can call GCP without static GCP credentials.
• Per-pod isolation.: Like IRSA, GCP Workload Identity provides per-pod isolation. Two pods with different ServiceAccounts get different identities and different permissions.

The GCP pattern is the GCP-native equivalent of IRSA. The mechanisms differ; the discipline is the same.

Migration

Migrating from static credentials to workload identity is a major project. Existing workloads have static credentials in environment variables, config files, secret stores. Each one needs to be migrated; the process is methodical.

• Inventory existing static credentials.: The first step is finding them all. Environment variable patterns, secret store entries, config file references. The inventory is the work plan; without it, the migration is open-ended.
• Replace one at a time.: Workloads are migrated one at a time. The static credential is replaced by workload identity; the workload is verified to work with the new identity; the static credential is removed.
• Verify.: After each migration, the workload is verified. Does it still work? Are the IAM permissions sufficient? Are there any code paths that still reach for the static credential? The verification catches partial migrations.
• Remove the static credential.: Once verified, the static credential is removed from the secret store. The workload identity is the only path; the static credential cannot be revived. The discipline produces irreversible improvement.
• Months-long project for large fleets.: Hundreds of workloads with static credentials take months to migrate. The pace is set by the team's capacity and the workloads' criticality. Higher-risk workloads migrate first; lower-risk follow.
• Worth it for the security gain.: Static credentials are a recurring source of incidents (credentials leaked, credentials stolen, credentials shared inappropriately). Eliminating them eliminates the incident class. The migration cost is one-time; the security benefit is permanent.

Workload identity pattern is one of the highest-leverage long-term security disciplines. Nova AI Ops integrates with cloud IAM and Kubernetes telemetry, surfaces remaining static credentials, and produces the migration-tracking report that the security team uses to drive the multi-month effort.