# 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.

## Related pages

* [GitHub, GitLab, and Cloud Trust Patterns](/architecture-api-crypto-and-identity/index-2/github-gitlab-oidc-and-cloud-trust-patterns.md)
* [JIT, PAM, Break-Glass, and Admin Access](/architecture-api-crypto-and-identity/index-2/jit-pam-break-glass-and-admin-access.md)

***

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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/architecture-api-crypto-and-identity/index-2/workload-federation-and-non-human-identities.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.