Chapter 16 — Cloud and container security: methods II
Lesson map
Lesson 16 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["16.1 Pod Security Standards"]
N2["16.2 Network policies"]
N3["16.3 Secrets"]
N4["16.4 Starting with warn"]
N5["16.5 Fixing workloads"]
N6["16.6 Recording progress"]
N7["Namespaces and labels"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX046"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["16.1 Pod Security Standards"]
N2["16.2 Network policies"]
N3["16.3 Secrets"]
N4["16.4 Starting with warn"]
N5["16.5 Fixing workloads"]
N6["16.6 Recording progress"]
N7["Namespaces and labels"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]
[Learning outcomes]
|
v
[16.1 Pod Security Standards]
|
v
[16.2 Network policies]
|
v
[16.3 Secrets]
|
v
[16.4 Starting with warn]
|
v
[16.5 Fixing workloads]
|
v
[16.6 Recording progress]
|
v
[Namespaces and labels]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) apply Pod Security Standards; (2) use network policies; (3) handle secrets safely.
16.1 Pod Security Standards
Kubernetes defines three profiles: Privileged, Baseline and Restricted. Restricted requires, among other things, running as non-root and dropping extra capabilities. Namespaces are labelled with the level to enforce. Privileged applies no restrictions, Baseline blocks known privilege escalations such as privileged containers and host namespaces, and Restricted adds hardening such as requiring a non-root user. At Cobalt, client-b's default was Privileged and the internal cluster's was Baseline, which is why both failed the baseline check. The labels make the expected level visible on each namespace, so a review can see at once which level applies.
16.2 Network policies
By default pods can talk to all other pods. A network policy limits this, for example allowing booking to reach only the API and email service. On the shared cluster, that default means one small client's workloads could connect to another client's database service if nothing else stopped them. Network policies are written in terms of labels, so Priya's flow list translates directly into rules: each allowed flow becomes an allow rule, and everything else is denied. The missing policy between booking and reports at Riverside Dental is the first one she writes.
16.3 Secrets
The Kubernetes good-practice guide for secrets advises encryption at rest, least-privilege access to secrets and avoiding secrets in images or source code. Secrets encryption at rest was one of the baseline checks client-b failed, so its stored secrets were readable by anyone with access to the cluster's storage layer. Least-privilege access matters just as much: the audit summary later shows the CI bot reading secrets, which may be needed but should be limited to the specific secret used for deployment. Secrets in images are worse still, because every copy of the image carries them.
16.4 Starting with warn
Pod Security admission supports warn and audit modes, which report violations without blocking. Priya uses these first. Warn mode returns a message to whoever submits a non-compliant pod, while audit mode records the violation in the audit log. Neither stops the pod, so client services keep running while Priya collects a list of workloads that would fail. That list becomes the work plan for each namespace, and only when it is empty does the namespace move to enforce. Audit mode also leaves a record in the logs for later comparison.
16.5 Fixing workloads
Most failures are fixed by setting a non-root user in the image and adding a security context. Setting a non-root user usually means adding a user in the image build and switching to it, then declaring in the pod's security context that the container must not run as root, with privilege escalation disabled and extra capabilities dropped. Workloads that write files may also need a writable volume, as the cron job later shows. Fixing the image rather than the policy keeps the protection in place.
16.6 Recording progress
Each namespace's level is tracked in the inventory. The inventory gains one field per namespace: the enforced Pod Security level. Priya can then answer which namespaces still run below Restricted with the same script that answers image questions. During the placement, the shared cluster's namespaces move from warn to enforce one at a time, and each move is recorded with its date, so the progress is visible in the repository history rather than in someone's memory. The field is also checked by the namespace label check.
Namespaces and labels
Labels are applied through the configuration repository, so a forgotten label shows up in review. Priya adds a check that every namespace has an enforce label, which catches new namespaces created without one. This idea comes from a known failure: after Kubernetes removed PodSecurityPolicy in version 1.25, clusters without replacement labels lost enforcement silently.
For network policies, she starts with a default deny for each client namespace and then adds allow rules for the flows on her list, linking the two pieces of work.
Checking support
Priya confirms the shared cluster's network plugin enforces policies before relying on them.
Order
Warn, then audit, then enforce, namespace by namespace.
Worked example
Warn mode on the shared cluster shows that reports runs as root. The team changes its image to use a non-root user, tests, and the namespace moves to enforce Restricted.
Synthetic case. Workloads are synthetic.
Errors and limits
Network policies only work if the cluster's network plugin supports them; check first.
Exercises
- EX046 — Profiles. Name the three Pod Security Standards profiles. Rubric: 3 = privileged, baseline, restricted; 2 = two; 1 = one; 0 = none.
- EX047 — Default traffic. What happens between pods without network policies? Rubric: 3 = all can talk; 2 = partial; 1 = vague; 0 = none.
- EX048 — Warn first. Why start Pod Security admission in warn mode? Rubric: 3 = see violations without blocking; 2 = partial; 1 = vague; 0 = none.
Synthesis
Apply workload controls gradually, observing before enforcing.
Continue studying — chapter 16 of 30
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →