Topic 7.2
Least Privilege & Short-Lived Credentials with OIDC
In one line
A long-lived cloud credential stored as a pipeline secret is a standing risk forever — OIDC lets a pipeline request a genuinely short-lived, scoped credential fresh for each run, with nothing long-lived to ever leak in the first place.
Key ideas
- 01
A genuinely common, real pattern this topic specifically improves on: storing a cloud provider's LONG-LIVED access key (an AWS IAM access key, say) as a pipeline secret, used for every deployment indefinitely — this credential, if it ever leaks (Topic 7.1's own risks), remains valid and exploitable until someone notices and manually rotates it, exactly the kind of standing risk Git's own course (Phase 7.5) and Kubernetes' own course (Phase 5.3) both warned about for long-lived secrets generally.
- 02
OIDC (OpenID Connect) lets a CI/CD platform act as a genuinely trusted IDENTITY PROVIDER that a cloud provider can directly verify — instead of storing a long-lived cloud credential as a secret at all, the pipeline presents a short-lived, cryptographically-signed OIDC TOKEN proving 'this is genuinely a run of workflow X in repository Y,' and the cloud provider exchanges that token for a temporary, narrowly-scoped credential valid only for the duration of that one specific pipeline run.
- 03
This means there is NO long-lived credential sitting in your pipeline's secrets store AT ALL for OIDC-based cloud access — nothing exists to leak in the first place through any of Topic 7.1's risk paths, since the actual, usable credential is generated fresh, used briefly, and expires automatically, all within the lifetime of one single pipeline run.
- 04
Configuring OIDC requires establishing TRUST between the cloud provider and the CI platform beforehand — an AWS IAM role configured to trust GitHub Actions' own OIDC provider, restricted to only accept tokens from a SPECIFIC repository (and optionally, a specific branch or environment), meaning even a stolen OIDC token from an UNRELATED repository couldn't be used to assume that role at all.
- 05
This is genuinely the SAME least-privilege principle every course in this collection has applied in its own specific context (Linux's dedicated service users, Docker's non-root containers, Kubernetes' scoped RBAC and ServiceAccounts) — now applied specifically to CLOUD credential access from a CI/CD pipeline: grant the narrowest possible, shortest-lived access that genuinely accomplishes the task, rather than a broad, permanent credential 'just in case.'
- 06
The original DevOps roadmap this course draws from names OIDC and short-lived cloud credentials directly (Section 26, CI/CD Security) as a genuinely current, real best practice — major cloud providers and CI platforms have converged on this exact pattern specifically because it removes an entire, well-documented class of real security incidents: a long-lived credential accidentally committed, logged, or leaked, remaining exploitable indefinitely until manually caught and rotated.
Code & diagrams
No long-lived secret exists to leak — the actual usable credential is generated fresh, per run, and expires quickly.
No AWS access key stored anywhere — the credential is requested fresh, scoped to just this repository, for this one run.
permissions:
id-token: write # lets this job request an OIDC token at all
contents: read
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Assume AWS role via OIDC — no stored access key needed
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789:role/github-actions-deploy-role
aws-region: us-east-1
# AWS verifies the OIDC token proves this is genuinely a run of
# THIS repository's workflow, then issues a short-lived credential
- name: Deploy — using the temporary, scoped credential
run: aws s3 sync ./dist s3://my-app-bucket/Explain it without notes
Why does an OIDC-based credential pose fundamentally less risk than a long-lived access key, even if both were somehow exposed in a pipeline's logs?
Why does trust need to be configured on the CLOUD PROVIDER's side, restricted to a specific repository, for OIDC to actually be secure?
Practice
If you have access to both a GitHub repository and a cloud provider account, set up OIDC-based authentication for a simple deployment step, confirming no long-lived cloud credential needs to be stored as a repository secret at all.
For a hypothetical pipeline currently using a long-lived static cloud credential, describe the specific configuration change needed on the cloud provider's side to migrate it to OIDC instead.
Trade-offs
- ↔
OIDC-based authentication is genuinely more secure than long-lived credentials, but it requires real, one-time setup effort on the cloud provider's side (configuring the trust relationship correctly, which varies by cloud provider and can be genuinely fiddly to get exactly right the first time) — for a very small, low-stakes project, a long-lived credential kept correctly in a secrets store may feel simpler to set up initially, though the ongoing risk of that standing credential existing indefinitely is exactly the real, growing cost OIDC is designed to eliminate.
Done when you can
I understand why a long-lived cloud credential stored as a pipeline secret is a genuine, ongoing standing risk.
I can explain how OIDC lets a pipeline authenticate without any long-lived credential existing at all.
I understand why the cloud provider's trust configuration must be scoped to a specific repository for OIDC to be secure.