CoursesAWS security engineeringIAM depth & escalation paths

Federation & killing static keys

Identity Center for humans, OIDC for CI, roles on instances.

Advanced35 min · lesson 3 of 15

The single highest-leverage IAM upgrade is deleting long-lived access keys. A key in a CI secret, a config file, or an env var is a bearer credential that never expires — copy it once and you own it forever. Federation replaces it with short-lived credentials minted on demand and scoped to the exact caller.

Humans via Identity Center, workloads via OIDC

For people, IAM Identity Center federates your existing IdP (Okta, Entra, Google) to permission sets that become short-lived role sessions — central management, one place to revoke, no IAM users. For CI/CD, AssumeRoleWithWebIdentity exchanges the platform’s signed OIDC token for temporary credentials, with a trust policy that pins the token’s claims to a specific repository and branch. No static secret exists to leak in either case.

GitHub Actions to AWS, zero stored keys
# Trust policy on the role the pipeline assumes. The condition pins the token
# to ONE repo and ONE branch — a fork or another repo cannot assume it.
{
"Effect": "Allow",
"Principal": { "Federated": "arn:aws:iam::222222222222:oidc-provider/token.actions.githubusercontent.com" },
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" },
"StringLike": { "token.actions.githubusercontent.com:sub": "repo:acme/api:ref:refs/heads/main" }
}
}
# The workflow needs id-token: write and NO aws-access-key secrets anywhere:
- uses: aws-actions/configure-aws-credentials@v4
with: { role-to-assume: arn:aws:iam::222222222222:role/gha-deploy, aws-region: eu-west-1 }

On-instance identity

Code running on AWS should never carry a baked-in key. EC2 instance roles (via IMDSv2), ECS task roles, and EKS IRSA all deliver short-lived, auto-rotated credentials through the metadata service or a projected token. Enforce IMDSv2 (token-required) so the older, SSRF-exploitable IMDSv1 cannot be abused to steal the instance role — a classic path from a web-app SSRF to cloud credentials.

Token exchange: no key at rest
1CI job / workload
has a platform identity
2signed OIDC token
claims: repo, branch, sa
3STS verifies + conditions
AssumeRoleWithWebIdentity
4short-lived creds
minutes-long, scoped, revocable
A captured token that already expired is worthless, and there was never a standing secret to steal.
A loose sub claim is worse than a stored key
Federation’s security is entirely in the trust-policy conditions. A subject like repo:acme/api:* trusts every branch and every pull request — including a malicious PR from a fork. Pin the sub to specific refs or environments, always assert the aud claim, and review these conditions like production code.