Chapter 24 — Cloud and container security: methods I
Lesson map
Lesson 24 published. Map, example, EX070.
flowchart TD
N0["Learning outcomes"]
N1["24.1 The method"]
N2["Lab — Lab — network reachability"]
N3["24.2 Lab result"]
N4["24.3 Egress too"]
N5["24.4 Testing safely"]
N6["24.5 Labels"]
N7["24.6 Monitoring"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX070"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["24.1 The method"]
N2["Lab — Lab — network reachability"]
N3["24.2 Lab result"]
N4["24.3 Egress too"]
N5["24.4 Testing safely"]
N6["24.5 Labels"]
N7["24.6 Monitoring"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX070"]
[Learning outcomes]
|
v
[24.1 The method]
|
v
[Lab — Lab — network reachability]
|
v
[24.2 Lab result]
|
v
[24.3 Egress too]
|
v
[24.4 Testing safely]
|
v
[24.5 Labels]
|
v
[24.6 Monitoring]
|
v
[Worked example] --> [Exercise EX070]
Learning outcomes
You will (1) design default-deny network policies; (2) compute reachability before and after; (3) allow only documented flows; (4) test policies safely.
24.1 The method
Start from the documented and observed flows (chapter 11), apply a default-deny policy to the namespace, then add allow rules for each legitimate flow. The Kubernetes network policy documentation explains that once a pod is selected by a policy, traffic not allowed by some policy is denied.
Starting with default deny means anything not explicitly allowed is blocked, so forgotten flows fail visibly rather than staying open silently. Adding allows one by one from the observed list documents every permitted path. Each allow rule can reference the flow it supports, which helps later reviewers.
Lab — Lab — network reachability
"""Reachability between synthetic pods: no policy vs default-deny with allow rules (stdlib only)."""
pods = ["web", "api", "db", "metrics"]
allow = {("web", "api"), ("api", "db"), ("metrics", "api"), ("metrics", "db")}
total = len(pods) * (len(pods) - 1)
print(f"no policies: {total}/{total} pod pairs reachable")
ok = sorted(f"{a}->{b}" for a in pods for b in pods if a != b and (a, b) in allow)
print(f"default deny + allows: {len(ok)}/{total} reachable: {', '.join(ok)}")
print("web->db reachable:", ("web", "db") in allow)
Run with python3 lab_netpol.py. Verified output:
no policies: 12/12 pod pairs reachable
default deny + allows: 4/12 reachable: api->db, metrics->api, metrics->db, web->api
web->db reachable: False
24.2 Lab result
With no policies, all 12 directed pod pairs among web, api, db and metrics are reachable. With default deny plus four allows, only 4 of 12 are: api->db, metrics->api, metrics->db and web->api. web->db is no longer reachable, so a flaw in the web pod could not reach the database directly.
Going from twelve reachable pairs to four removes two-thirds of possible paths. If the web pod were compromised, an attacker would have to go through the API, which authenticates requests and limits what can be read.
24.3 Egress too
Default deny should cover egress as well as ingress; DNS egress must be allowed explicitly or name resolution fails.
Without egress rules, a compromised pod could still send data out freely even if no one can reach it. Forgetting DNS is a common mistake: pods cannot resolve service names, which looks like a broken application. Elena includes a DNS allow in her policy template for every namespace. Allowed external destinations, such as the image registry, are listed by name with the reason for each.
24.4 Testing safely
Policies are applied first in the test cluster, with connection tests for every allowed and a sample of denied pairs. Some network plugins offer audit modes; otherwise staged rollout by namespace is used.
Testing every allowed pair confirms nothing legitimate is broken; testing a sample of denied pairs confirms the policy actually blocks. Audit modes log what would be blocked without blocking it, which is ideal for finding missed flows. Staged rollout limits disruption if something was missed. Each test result is recorded with the policy version applied.
24.5 Labels
Policies select pods by labels; inconsistent labels cause surprises, so label standards are enforced in the pipeline.
A policy selecting pods with app=api will not apply to a pod labelled application=api, leaving it unprotected or blocked unexpectedly. Enforcing a label standard in the pipeline catches such differences before deployment. Elena adds a check that every pod carries the required labels. The standard defines a small set of keys, such as app, tier and team, with allowed values. Pipelines reject manifests missing them, so policies can rely on the labels being present and spelled consistently.
24.6 Monitoring
Denied connection logs show legitimate traffic that was missed.
Denied connections after rollout usually mean a legitimate flow was missed, such as a monthly report job. Logs give the source, destination and port, so the team can add the right allow quickly. Unexpected denials that do not match any known service may indicate misuse. Elena sets an alert when denials for one namespace rise sharply after a policy change, and the alert links to the change that preceded it. In the first week after rollout, the team reviews every distinct denied pair daily, then weekly once the list stabilises.
Rollout order
Namespaces are rolled out from least to most critical, so lessons from simple services improve the policies for meterhub ingest, which goes last.
Worked example
In meterhub's test cluster, the first default-deny rollout breaks metrics collection because the metrics stack scrapes through a port not in the documented flows. The denied-connection log shows it within minutes; an allow rule is added and the test repeated before production rollout.
Synthetic case. Pods and flows are synthetic.
Errors and limits
Network policies depend on the network plugin enforcing them; confirm the cluster's plugin supports them.
Exercises
- EX070 — Lab counts. How many pairs were reachable before and after? Rubric: 3 = 12/12 then 4/12; 2 = partial; 1 = vague; 0 = none.
- EX071 — web->db. Why does blocking web->db matter? Rubric: 3 = web flaw cannot reach database directly; 2 = partial; 1 = vague; 0 = none.
- EX072 — Metrics breakage. What broke and how was it found? Rubric: 3 = metrics scraping; denied log; 2 = partial; 1 = vague; 0 = none.
Synthesis
Default deny plus documented allows shrinks reachability sharply.
Continue studying — chapter 24 of 50
← Chapter 23 (draft) · Course chapter index · Chapter 25 (draft) →