Module 02 · Runtime and cloud · 55 min · You are: Platform team
Cloud metadata and OIDC
In this module
- You learn: Follow a request-forgery path to a mock metadata endpoint and test CI trust.
- You do: Use the local metadata mock and fake role credentials, close the path with an application host allowlist, IMDSv2 and network policy, then narrow OIDC trust to a production environment.
- You end with: S08 is covered and S08a records a dated public HTTPS exception.
A link-preview endpoint can make requests from inside the workload. Independently limit the app, metadata protocol and network; make cloud trust exact.
Open this module in the interactive course to track progress.
Change journey practised: Surface → Test → Measure → Prove
Concepts
- Surface: metadata and cloud role trust
- IMDSv2 requires a session token before metadata credentials are returned.
- Trust boundary
- A GitHub OIDC subject identifies the repository, event or environment.
- Evidence
- The local mock returns sample values that open no cloud account.
Files to know
Open them in your editor or on GitHub; the bullets say what to look at.
start/infra/iam.tf(reference): Reference file for the runtime surface.- This line shows the trust boundary or the evidence shape. L1
start/tools/token-exchange/exchange.mjs(reference): Bounded lab fixture for this module.- Use this fixture to test the hypothesis safely. L3
Steps
1. Test: trace a request to the metadata mock
Start the local mock. For this test only, apply the lab egress relaxation, then request its sample role metadata through checkout. The sample values open no cloud account.
kubectl apply -f devsecops-lab/labs/imds/namespace.yaml -f devsecops-lab/labs/imds/deployment.yaml -f devsecops-lab/labs/imds/service.yaml
Wait until the metadata mock is ready, then lift only the named lab egress rule for one request.
kubectl apply -f devsecops-lab/labs/imds/allow-egress-for-lab.yaml
2. Measure and prove: close three independent paths
Add the application host allowlist, require IMDSv2 in the mock and infrastructure configuration, and restore default-deny egress. Print only OIDC claim fields, never the bearer token. Narrow trust to the exact production environment, then record S08 and the expiring S08a exception.
kubectl delete -f devsecops-lab/labs/imds/allow-egress-for-lab.yaml
The metadata request should now time out from checkout. Verify the OIDC verifier prints DENY for a pull request and ALLOW only for the protected environment.
cd devsecops-lab && LAB_OIDC_CLAIMS=docs/fixtures/oidc-production.json node tools/token-exchange/exchange.mjs
Simplified for the workshop
The metadata service is a local mock, and its sample credentials open nothing. The CI token verifier uses claims supplied by the workflow and does not contact a cloud provider.
The lab checks parse files only. They never run code from the learner repository.
Break it on purpose: Break it: a pull request matches a broad subject
A change appears to work because the easiest test is blocked by another control. Lift only the named lab control for one test and isolate the boundary under study.
You practise: You practise separating controls, predicting signals and restoring the runtime to its safe default.
1. Break it
cd devsecops-lab && git diff -- deploy/ infra/
2. What you see
Expected: the tested path stops at this control. You get a request or identity accepted that should have been denied. Compare the observed log with the pre-test prediction.
3. Fix it yourself
Restore the control and prove the same path is denied. Done when the register names the result, owner, evidence and retest date.
Hint 1
Trace the request from application to destination, including the network path.
Hint 2
Test each independent control alone, then restore all of them.
The fix
Follow the module policy files and reapply the default deny before continuing.
cd devsecops-lab && ./scripts/validate.sh
After you fixed it: the five questions
- What failed?
- A runtime or identity boundary allowed an unintended pivot.
- How was it detected?
- The bounded request or verifier returned an unexpected success.
- Who responds?
- The owning team in the register: product for the app, platform for cluster and cloud policy.
- How is it corrected?
- Close the specific boundary and repeat the request or identity test.
- How is it prevented?
- Keep an exact parse-only rule and a dated retest in the shared evidence register.
Quiz
- Why does the metadata mock belong in this lab?
- It provides a bounded local target whose sample credentials open no cloud account.
- It proves that real cloud credentials are safe to expose.
- It removes the need to inspect network policy.
- What does an exact OIDC subject condition do?
- Limits which repository or environment identity may assume the role.
- Encrypts credentials in GitHub logs.
- Proves that every commit is reviewed.
- What is the first response to an unexpected workflow?
- Preserve run and commit evidence, disable the path, and rotate exposed credentials.
- Delete every workflow and erase the repository history.
- Wait until a scanner confirms data was stolen.
Answers
- It provides a bounded local target whose sample credentials open no cloud account. The target must be contained and disposable.
- Limits which repository or environment identity may assume the role. Trust conditions define eligible identities.
- Preserve run and commit evidence, disable the path, and rotate exposed credentials. Containment and evidence both matter; rotate credentials that could be exposed.
Field note
I test the same hypothesis after each control. That shows which layer stopped the path and whether another layer still works.