Workload identity
A verifiable identity assigned to a running service or job. It needs bounded credentials, audience and authorization rules just as a human identity does.
- Also called
- workload identity federation
Covered in
Workload identity federation: short-lived, scoped identities for services and CI
Trace how a running workload obtains a short-lived identity, write cloud trust policies that match immutable claims instead of names or wildcards, and keep the resulting credential limited by audience and authorization.
Review cloud permissions and role trust together
Distinguish who can obtain a cloud identity from what that identity can do, then test the effective access path.
Authenticate workloads and authorize their service actions
Use service identities, mutual TLS and function permissions without mistaking an encrypted connection for complete authorization.
Apply a security baseline across AWS, Azure and Google Cloud
Give workloads platform identities instead of keys, guard the instance metadata endpoint, block public storage, keep audit logs past the default retention, close inbound admin ports and use the native secret store, with tested Terraform for AWS, Azure and Google Cloud.
Harden managed Kubernetes on EKS, AKS and GKE
Know what your provider secures and what you still own, then lock down API access, cloud identity, nodes, pod privileges and admission with settings that are generally available in Kubernetes 1.37, checked against the CIS and NSA/CISA baselines.
Secrets at runtime: Vault, Kubernetes Secrets, CSI driver, External Secrets and SOPS
How a running workload should get its credentials: encrypt Kubernetes Secrets with a KMS v2 provider and lock down RBAC, mount from an external store with the Secrets Store CSI Driver, sync with External Secrets Operator, issue dynamic credentials with Vault and its Agent Injector, keep Git copies encrypted with SOPS, and make rotation reach the process.
Practice: IAM trust policy lab: Evaluate a role trust policy against the confused deputy