Module 01 · Runtime and cloud · 40 min · You are: Platform team

A pod in a box

In this module

You learn: Trace what a compromised process can reach inside its namespace.
You do: Inspect the checkout security context and NetworkPolicy, test service-account access and egress, then prove the namespace boundary.
You end with: S07 records the measured pod, API and network limits.

A process inside a container can use the identity and network available to it. Namespace defaults and least privilege constrain the pivot.

Open this module in the interactive course to track progress.

Change journey practised: Surface → Test → Measure → Prove

Concepts

Surface: pod identity and egress: kind: NetworkPolicy
Trust boundary: A read-only root filesystem does not remove network credentials.
Evidence: Test what the pod can reach, not just its manifest.

Files to know

Open them in your editor or on GitHub; the bullets say what to look at.

start/deploy/checkout/networkpolicy.yaml (reference): Reference file for the runtime surface.
1. This line shows the trust boundary or the evidence shape. L2
start/deploy/checkout/serviceaccount.yaml (reference): Bounded lab fixture for this module.
1. Use this fixture to test the hypothesis safely. L6

Steps

1. Test: inspect the pod boundary

Check the service account, namespace policy and what the checkout pod can reach. Predict the expected API and egress result before running the probes.

kubectl auth can-i get secrets -n checkout-dev --as=system:serviceaccount:checkout-dev:checkout

The service account should not read Secrets. Check a DNS request and the attempt to reach metadata separately.

kubectl -n checkout-dev get networkpolicy checkout -o yaml

2. Measure and prove: record runtime limits

Disable automatic API token mounting, retain default-deny egress and allow only required DNS. Repeat the probes and record S07.

kubectl -n checkout-dev get serviceaccount checkout -o yaml

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: egress has no destination limit

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.

Report a problem with this module