PS Product SecurityKnowledge Base

🤖 Workload Federation and Non-Human Identities

Intro: Most cloud breaches do not require stolen passwords. They require machine identities that are broader, longer-lived, or less visible than teams realize. This page focuses on how to reduce that exposure.

What this page includes

  • non-human identity types that matter in practice
  • why workload federation is safer than distributing static keys
  • common review questions for service accounts and managed identities
  • how to shrink the blast radius of machine identities

Identity types to distinguish clearly

  • workload identities: pods, tasks, VMs, serverless functions;
  • service accounts or principals: the cloud-side identity objects those workloads use;
  • pipeline identities: CI jobs or deployment controllers;
  • operator identities: humans with elevated platform permissions.

Why federation is the safer default

Federation removes the need to store powerful long-lived cloud keys in CI, repo settings, or application config. Current vendor guidance strongly favors short-lived exchanges over static service-account keys and secrets.

Review checklist

Ask of every machine identity:

  • who can mint or obtain this identity?
  • what conditions must be true for that minting to happen?
  • can the identity read secrets, write artifacts, or deploy code?
  • does the identity work outside the intended environment?
  • how would we detect misuse?

Safer defaults

  • one identity per workload or deployment class where practical;
  • separate read, build, and deploy identities;
  • keep secret-read access narrower than deployment-read access;
  • avoid identities that can both change runtime and change their own permissions.

Cross-cloud examples

  • GCP: Workload Identity Federation for GKE is the recommended path for workloads to access Google Cloud APIs without service-account key files.
  • Azure: managed identities and Microsoft Entra workload identity reduce the need to handle credentials directly.
  • GitHub Actions: OIDC allows cloud access without storing long-lived cloud secrets in the repository or organization.

Anti-patterns

  • a single CI identity with broad read-write access to registry, secrets, and deployment APIs;
  • kube service accounts with indirect reach into many cloud services;
  • user-assigned or shared machine identities reused for unrelated workloads without clear ownership.

Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.