rootnode-academy/content/root/root-09-kubernetes-security/m03-network-and-supplychain-security/01-lesson-network-supplychain.md

NetworkPolicy as a Security Control & Supply Chain Trust

NetworkPolicy, revisited as a security posture

ROOT 07 introduced NetworkPolicy architecturally: Kubernetes doesn't isolate Pod-to-Pod traffic by default, and NetworkPolicy is how you declare intended reachability. Here, the same mechanism is the point of a deliberate SECURITY practice: default deny.

A default-deny policy blocks all traffic to selected Pods, and you then explicitly allow only what's actually needed:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector: {}      # selects EVERY Pod in the namespace
  policyTypes: ["Ingress"]

An empty podSelector: {} with no ingress rules means "select every Pod, allow nothing in" — the network equivalent of the SecurityContext principle from earlier in this course: start from nothing, add back only what's proven necessary. This is exactly the opposite of Kubernetes' un-configured default (everything open), which is precisely why it has to be declared explicitly rather than relying on any built-in setting.

Egress restriction works the same way in reverse — restricting what a Pod can call OUT to, not just what can call IN. A compromised Pod that can freely make outbound connections to anything is far more dangerous (data exfiltration, calling out to an attacker's server) than one restricted to only the specific destinations it legitimately needs.

Supply chain: trusting what you run before it ever starts

Everything covered so far in this course assumes the container image itself is trustworthy. Supply-chain security is about that assumption specifically:

• Image-pull secrets — when pulling from a private registry, the cluster needs credentials to authenticate. Storing and using these correctly (rather than, say, a publicly-readable registry with no access control) is a basic supply-chain control: only images from a trusted, access-controlled source get pulled at all.
• Minimizing image footprint (referenced here, not a hands-on Lab in this module) — a smaller image means fewer packages, fewer known CVEs, and a smaller attack surface if the image is ever compromised.

TLS at the Ingress layer: protecting data in transit

Recall ROOT 07's Ingress lesson — routing external HTTP(S) traffic by hostname/path. Configuring TLS termination at that same Ingress layer means traffic between users and your cluster is encrypted, protecting against interception on the network path. This is a security concern layered on top of the same architectural mechanism, the same relationship NetworkPolicy has to its ROOT 07 introduction.

Instructor Notes

Approximate timing: 15 minutes read; 10 minutes live.

Likely misconceptions to watch for:

• Students sometimes think "default deny" means blocking ALL traffic including what the application needs to function. Clarify: default deny is the STARTING point; you then add specific allow rules for exactly what's needed — the goal state is fully functional AND fully intentional, not non-functional.
• Egress restriction is sometimes seen as less important than ingress. Emphasize the exfiltration angle explicitly — a compromised Pod's outbound reach is just as much a real risk as inbound exposure.

Discussion question: "Why is 'default deny, then explicitly allow' a better starting posture than 'default allow, then explicitly block known-bad traffic'?" (Answer: default-deny means a NEW, unanticipated attempt to reach or leave a Pod is blocked by default; default-allow means anything not YET identified as bad gets through — you're always one step behind an attacker under the second model.)

Optional extension: ask what a real team would want to verify before trusting a publicly-available container image from an unfamiliar source, beyond just "does it work" — a good bridge into image scanning/provenance concepts (not built as a hands-on Lab in this course, but worth naming as a real practice).