# Guided Exercise: Planning a Pod Hardening Checklist

Paper-and-thinking exercise before the Labs.

## The scenario

You're handed a Pod spec for a small internal API with NO `securityContext` set at all — the
fully-default, unhardened case from the demonstration. Your team lead asks you to harden it
before it ships.

## Your task

Without writing the actual YAML yet, answer these:

1. List the settings you'd add, in the order you'd verify them (hint: there are at least three
   distinct concerns from the lesson — user/root, filesystem, capabilities).
2. For each setting, name ONE way you'd notice if you'd broken the application by adding it
   (what would the failure actually look like?).
3. If the application genuinely needs to write a cache file to disk, does that mean you should
   skip `readOnlyRootFilesystem` entirely? What's the more precise fix?
4. Suppose after hardening, the container still runs fine but a security scan flags that it
   still has the `NET_RAW` capability. What's the most likely reason, and what's the fix?

## A worked answer to check yourself against

1. In a reasonable order: (a) `runAsNonRoot`/`runAsUser` — a fundamental identity change,
   surfaces image assumptions fastest; (b) `capabilities: drop: ["ALL"]` — narrow, usually safe
   for a typical web API; (c) `readOnlyRootFilesystem: true` — most likely to need an
   accompanying volume, so verify last once the others are confirmed working.
2. (a) Pod fails to start entirely (`CrashLoopBackOff` or an immediate error) if the image
   assumed root. (b) The application errors on a specific operation that needed a capability
   you dropped (e.g. failing to bind a privileged port). (c) A write operation fails at runtime
   (a log line, an exception) the first time the app tries to write to disk.
3. No — the fix is mounting an explicit `emptyDir` volume at the specific path the cache needs,
   keeping the rest of the filesystem read-only rather than abandoning the protection entirely.
4. Most likely: `capabilities: drop: ["ALL"]` was never actually applied (a YAML indentation
   mistake, or it was added to the Pod's securityContext instead of the container's — capability
   drops are container-level, not Pod-level). The fix is verifying the drop is actually present
   on the CONTAINER's securityContext specifically.

## Instructor Notes

**Facilitation:** Question 4 is deliberately tricky — Pod-level vs. container-level
`securityContext` fields is a real, common source of "I set this and it didn't work" confusion
worth surfacing here before students hit it in a Lab.

**Approximate timing:** 15 minutes live with discussion; 12-15 minutes self-paced.

**Optional extension:** ask students to identify which of the settings in this exercise would
be MOST valuable to apply first if they could only add one to a large, existing fleet of
unhardened Pods under time pressure, and why.