🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🕸️ धडा 11 — Kubernetes secrets आणि network policies: आरशातले उलटे अक्षर म्हणजे कुलूप नाही

📍 तुम्ही इथे आहात: 16 पैकी धडा 11 · मागील: lesson-10-k8s-rbac · पुढील: lesson-12-admission

📦 या ब्रँचमध्ये काय आहे

धडे 01–10, आणि प्रत्येक नव्या cluster मध्ये असणारी दोन आश्चर्ये. पहिले: Kubernetes Secret फक्त base64 असते — एक encoding, encryption नाही — जोपर्यंत तुम्ही encryption at rest चालू करत नाही किंवा खरे गुपित external store मध्ये ठेवत नाही. दुसरे: प्रत्येक pod इतर प्रत्येक pod शी बोलू शकतो, जोपर्यंत एखादी NetworkPolicy त्याला select करत नाही — आणि तेही फक्त cluster चा network plugin (CNI) policies लागू करत असेल तरच. तुम्ही दोन्ही शिकता, आणि default-deny pattern सुद्धा.

sec/cloud.py — netpol_allows(policies, src_labels, dst_labels, port)
sec/demo.py — python3 sec/demo.py k8s_network
sec/test_sec.py — check L11

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

गुप्त पाकीट. ऐश्वर्या database चा password "SECRET" असे लिहिलेल्या पाकिटात ठेवते. पण आत password कुलूपबंद नाही — तो फक्त आरशातल्या उलट्या अक्षरांत लिहिलेला आहे. ज्याच्याकडे आरसा आहे (आणि आरसा सगळ्यांकडेच असतो) तो वाचू शकतो. हेच base64. ते खरोखर गुप्त करायचे असेल, तर कार्यालयाने चावी-तिजोरीतल्या चावीने पाकिटाला कुलूप लावायला हवे (KMS सह encryption at rest), किंवा password चावी-तिजोरीतच ठेवून गरज असेल तेव्हाच आणायला हवा (external secret store).

वऱ्हांडे. शाळेच्या नव्या इमारतीत प्रत्येक दार उघडे असते. कोणताही विद्यार्थी शिक्षक-खोलीत, server room मध्ये, स्वयंपाकघरात जाऊ शकतो. कार्यालय एखाद्या दारावर यादी घेऊन पहारेकरी ठेवू शकते: "फक्त निकाल-मदतनीस, आणि फक्त 5432 क्रमांकाच्या बाजूच्या दारातून."

पहारेकऱ्यांबद्दल दोन नियम:

पहारेकरी नसलेले दार सगळ्यांसाठी उघडेच राहते. म्हणून कार्यालय सुरुवातीला प्रत्येक दारावर रिकामी यादी — "कोणीच नाही" — घेऊन पहारेकरी ठेवते, आणि मग नावे जोडते. हेच default-deny.
पहारेकऱ्याची यादी फक्त कागद आहे. इमारतीत पहारेकरी सेवाच नसेल (policies लागू करणारा CNI), तर तो कागद काहीच करत नाही, आणि कोणी तुम्हाला सांगतही नाही.

🗺️ आकृती

flowchart LR
    r["🍳 results-api"] -->|"5432 ✓"| pg["📒 postgres<br/>NetworkPolicy: from app=results-api, port 5432"]
    n["📢 notices-api"] -. "5432 ✗" .-> pg
    r -. "22 ✗" .-> pg
    w["🌐 web (no policy selects it)"]
    any["any pod"] -->|"✓ everything allowed<br/>until default-deny"| w
    s["🔑 Secret password: U3VtbWVy…<br/>base64 -d → readable"] --> k["🗝️ encryption at rest (KMS)<br/>or External Secrets"]

🗺️ काढलेली आकृती + एक lab: https://school-edh.pages.dev/security/lesson-diagrams.html#l11

❓ काय

Secret — छोटी संवेदनशील values (passwords, tokens, keys) ठेवणारा Kubernetes object. Binary data YAML मध्ये बसावा म्हणून values base64-encoded असतात. Base64 हे encryption नाही: base64 -d ते उलटे करते, कोणतीही key लागत नाही.
Secrets कुठे राहतात — etcd मध्ये, cluster च्या database मध्ये. Encryption at rest नसेल, तर etcd backup किंवा disk snapshot मिळवणारा कोणीही प्रत्येक Secret वाचू शकतो.
Secrets साठी encryption at rest — API server Secrets etcd मध्ये लिहिण्याआधी encrypt करतो, जे EncryptionConfiguration file ने set up केले जाते. सर्वात चांगला provider म्हणजे KMS v2: cloud KMS मधली key data keys गुंडाळते (envelope encryption, धडा 07). EKS वर, नव्या versions मध्ये default envelope encryption येते, आणि Secrets साठी तुम्ही तुमची स्वतःची KMS key निवडू शकता, म्हणजे तिचे नियंत्रण आणि audit तुमच्याकडे राहते. अस्तित्वात असलेली Secrets पुन्हा लिहिली गेल्यावरच encrypt होतात.
Secrets कोण वाचू शकतो — हे अजूनही RBAC (धडा 10) ठरवते. secrets वर get/list, किंवा namespace मध्ये pods वर create, ते वाचायला पुरेसे आहे. API ज्याला वाचू देतो त्याच्यापासून encryption at rest संरक्षण देत नाही.
External secret stores — खरी value AWS Secrets Manager, SSM Parameter Store किंवा HashiCorp Vault मध्ये ठेवा. External Secrets Operator ती Kubernetes Secret मध्ये copy करतो आणि refresh करतो; Secrets Store CSI Driver ती file म्हणून mount करतो. Rotation एकाच ठिकाणी होते.
NetworkPolicy — ती ज्या pods ना (label ने) select करते त्यांच्यासाठी परवानगी असलेल्या traffic ची यादी: ingress (कोण आत येऊ शकतो) आणि egress (ते कुठे जाऊ शकतात), pod labels, namespace labels किंवा IP ranges, आणि ports नुसार.
प्रत्येकाला आश्चर्य वाटणारे दोन नियम:
- कोणतीही policy select न करणारा pod आत आणि बाहेर सगळे traffic चालू देतो;
- एकदा कोणत्याही policy ने pod ला ingress (किंवा egress) साठी select केले, की फक्त एखाद्या policy ने परवानगी दिलेलेच आत जाते — policies RBAC सारख्या बेरीज होतात; deny नियम नसतात.
Default-deny — podSelector: {} (namespace मधला प्रत्येक pod) असलेली आणि कोणताही allow नियम नसलेली policy. मग छोट्या allow policies जोडा. DNS लक्षात ठेवा: default-deny egress असेल तर pods ना port 53 वर kube-dns पर्यंत पोहोचायची परवानगी हवी.
CNI ने ती लागू करायला हवी — NetworkPolicy फक्त एक API object आहे. Calico, Cilium आणि Amazon VPC CNI (network policy चालू केल्यावर) ती लागू करतात. काही plugins (उदाहरणार्थ साधे Flannel) objects स्वीकारतात आणि त्यांच्याकडे दुर्लक्ष करतात.

🤔 का

कारण दोन्ही defaults security च्या दृष्टीने चुकीच्या दिशेला आहेत. एका pod मध्ये shell मिळवणारा attacker (धडा 01 मधले injection, धडा 13 मधली असुरक्षित library) मग database, cache, metrics endpoints आणि इतर teams च्या services पर्यंत पोहोचू शकतो — जोपर्यंत एखादी policy त्याला थांबवत नाही. आणि सुरक्षित "दिसणारे" Secret backups, CI logs आणि kubectl get -o yaml output मध्ये अशा स्वरूपात copy होते जे कोणीही decode करू शकतो. Default-deny आणि encrypted, बाहेरून managed secrets मुळे एक बिघडलेला pod फक्त एक बिघडलेला pod राहतो — पूर्ण शाळा नाही.

🔧 कसे (या repo मध्ये)

sec/cloud.py मधले netpol_allows(policies, src_labels, dst_labels, port) pod कडे येणाऱ्या ingress चे model करते:

ज्या policies चे सगळे pod labels destination pod शी जुळतात त्या शोधा;
कोणतीच त्याला select करत नसेल → True (सगळ्यांसाठी उघडा);
नाहीतर → तेव्हाच allowed जेव्हा select करणाऱ्या एखाद्या policy चे सगळे from labels source शी जुळतात आणि port त्याच्या ports मध्ये असतो.

रिकामा pod={} प्रत्येक pod select करतो, आणि ports=[] काहीच allow करत नाही — दोन्ही मिळून default-deny. sec/demo.py मधले k8s_network() postgres pods वर एक policy लावते. Snippet हे सुद्धा दाखवतो की Secret ची value base64 मध्ये कशी दिसते — धडा 07 च्या scan मधला काल्पनिक password वापरून.

🧪 करून पाहा

python3 sec/demo.py k8s_network
python3 - <<'EOF'
import sys, base64; sys.path.insert(0, "sec"); from cloud import netpol_allows
deny_all = dict(pod={}, ports=[], **{"from": {}})                                  # selects every pod, allows nothing
db_rule  = dict(pod={"app": "postgres"}, ports=[5432], **{"from": {"app": "results-api"}})
web_rule = dict(pod={"app": "web"}, ports=[8080], **{"from": {"app": "ingress"}})
tries = (({"app": "notices-api"}, {"app": "web"}, 8080), ({"app": "ingress"}, {"app": "web"}, 8080),
         ({"app": "results-api"}, {"app": "postgres"}, 5432), ({"app": "web"}, {"app": "postgres"}, 5432))
for name, pols in (("no policies", []), ("default-deny only", [deny_all]), ("default-deny + 2 allows", [deny_all, db_rule, web_rule])):
    print(f"── {name}")
    for src, dst, port in tries:
        print(f"   {src['app']:<12} → {dst['app']}:{port:<5} {'allowed' if netpol_allows(pols, src, dst, port) else 'blocked'}")
stored = base64.b64encode(b"Summer2026!school").decode()
print(f"── a Secret as the API server stores it: password: {stored}")
print(f"   anyone who can read it runs base64 -d → {base64.b64decode(stored).decode()}")
EOF
python3 sec/test_sec.py

✅ तपासा — तुम्हाला काय दिसायला हवे

k8s_network हे छापते:

═══ k8s_network ═══
── NetworkPolicy on the database pods: only results-api, only 5432
   results-api  → postgres:5432  allowed
   notices-api  → postgres:5432  blocked
   results-api  → postgres:22    blocked
   pods with no policy selecting them accept everything → True — start every namespace with default-deny
   Kubernetes Secrets are only base64 — enable encryption at rest, or use an external secret store

✅ done — every door checked

तुमचा snippet हे छापतो:

── no policies
   notices-api  → web:8080  allowed
   ingress      → web:8080  allowed
   results-api  → postgres:5432  allowed
   web          → postgres:5432  allowed
── default-deny only
   notices-api  → web:8080  blocked
   ingress      → web:8080  blocked
   results-api  → postgres:5432  blocked
   web          → postgres:5432  blocked
── default-deny + 2 allows
   notices-api  → web:8080  blocked
   ingress      → web:8080  allowed
   results-api  → postgres:5432  allowed
   web          → postgres:5432  blocked
── a Secret as the API server stores it: password: U3VtbWVyMjAyNiFzY2hvb2w=
   anyone who can read it runs base64 -d → Summer2026!school

Tests मध्ये ✅ L11 a NetworkPolicy lets only the named source in आहे आणि शेवट 16/16 passed ने होतो.

🏁 तुम्ही आत्ताच काय सिद्ध केले

कोणतीही policy नसताना चारही connections चालतात — अगदी web → postgres सुद्धा, जे कोणालाच नको होते. फक्त default-deny सगळेच बंद करते (सुरक्षित, पण app बंद पडते). Default-deny आणि दोन छोटे allow नियम शाळेला हवे असलेले नेमके दोन मार्ग देतात, आणि बाकीचे दोन बंद राहतात. Policies बेरीज होतात: allows ना deny "काढून टाकावा" लागला नाही. आणि "गुप्त" password एका ओळीत, कोणत्याही key शिवाय, base64 मधून परत आला.

⚠️ नेहमीच्या चुका

ज्या cluster चा CNI policies लागू करत नाही त्यावर policies लिहिणे — सगळे ठीक दिसते आणि काहीच block होत नाही (खऱ्या connection ने test करा, खाली पाहा)
फक्त काही "महत्त्वाच्या" pods साठी policies — बाकी प्रत्येक pod सगळ्यांसाठी उघडा राहतो
DNS allow शिवाय default-deny egress — प्रत्येक lookup fail होतो आणि app बिघडलेले दिसते
database वर ingress allow, पण API वर default-deny egress आणि database कडे कोणताही egress allow नाही — traffic साठी दोन्ही बाजू उघड्या असाव्या लागतात
असे label वापरून pods select करणे जे दुसऱ्या team च्या pods वरही असते (app: api)
"ते encoded आहेत म्हणून" Git मध्ये Secrets; kubectl get secret -o yaml ticket मध्ये paste करणे
encryption at rest चालू केले, पण जुनी Secrets कधीच पुन्हा लिहिली नाहीत, म्हणून ती etcd मध्ये अजूनही साधी (plain) आहेत
RBAC ज्याला get secrets करू देते अशा user ला encryption at rest थांबवते असे मानणे — ते थांबवत नाही

🏭 प्रत्यक्ष वापरात

खऱ्या account वर — namespace साठी default-deny, एक DNS allow, आणि शाळेला हवे असलेले दोन मार्ग:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny, namespace: school }
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: allow-dns, namespace: school }
spec:
  podSelector: {}
  policyTypes: [Egress]
  egress:
    - to:
        - namespaceSelector: { matchLabels: { kubernetes.io/metadata.name: kube-system } }
          podSelector: { matchLabels: { k8s-app: kube-dns } }
      ports: [{ protocol: UDP, port: 53 }, { protocol: TCP, port: 53 }]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: postgres-from-results-api, namespace: school }
spec:
  podSelector: { matchLabels: { app: postgres } }
  policyTypes: [Ingress]
  ingress:
    - from: [{ podSelector: { matchLabels: { app: results-api } } }]
      ports: [{ protocol: TCP, port: 5432 }]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: results-api-to-postgres, namespace: school }
spec:
  podSelector: { matchLabels: { app: results-api } }
  policyTypes: [Egress]
  egress:
    - to: [{ podSelector: { matchLabels: { app: postgres } } }]
      ports: [{ protocol: TCP, port: 5432 }]

CNI ती लागू करतो हे सिद्ध करा — चुकीचे label असलेला एक तात्पुरता pod fail व्हायला हवा, आणि योग्य label असलेला connect व्हायला हवा:

kubectl -n school run np-test --rm -it --restart=Never --image=busybox:1.36 \
    --labels app=notices-api -- nc -zv -w 2 postgres 5432      # expect: timed out
kubectl -n school run np-test --rm -it --restart=Never --image=busybox:1.36 \
    --labels app=results-api -- nc -zv -w 2 postgres 5432      # expect: open

Amazon VPC CNI असलेल्या EKS वर, add-on configuration मध्ये policy enforcement चालू करा ({"enableNetworkPolicy": "true"}), किंवा Calico किंवा Cilium चालवा.

Secrets साठी encryption at rest — तुम्ही स्वतः चालवत असलेल्या cluster वर, --encryption-provider-config ने API server ला दिलेली EncryptionConfiguration:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources: ["secrets"]
    providers:
      - kms:
          apiVersion: v2
          name: school-kms
          endpoint: unix:///var/run/kmsplugin/socket.sock
          timeout: 3s
      - identity: {}        # only so Secrets written before the change can still be read

मग प्रत्येक Secret पुन्हा लिहा, म्हणजे ती encrypted स्वरूपात साठवली जातील:

kubectl get secrets --all-namespaces -o json | kubectl replace -f -

EKS वर, Secrets साठी तुमची स्वतःची KMS key निवडा:

aws eks associate-encryption-config --cluster-name school \
    --encryption-config '[{"resources":["secrets"],"provider":{"keyArn":"arn:aws:kms:ap-south-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab"}}]'

External Secrets Operator — password AWS Secrets Manager मध्ये राहतो; operator Kubernetes Secret results-db तयार करतो आणि refresh करतो:

apiVersion: external-secrets.io/v1
kind: SecretStore
metadata: { name: aws-secrets, namespace: school }
spec:
  provider:
    aws:
      service: SecretsManager
      region: ap-south-1
      auth:
        jwt:
          serviceAccountRef: { name: external-secrets-reader }
---
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata: { name: results-db, namespace: school }
spec:
  refreshInterval: 1h
  secretStoreRef: { name: aws-secrets, kind: SecretStore }
  target: { name: results-db }
  data:
    - secretKey: password
      remoteRef: { key: school/results-db, property: password }

(जुन्या operator releases मध्ये external-secrets.io/v1beta1 वापरले जाते; तुम्ही चालवत असलेले version तपासा.)

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: namespace मध्ये default-deny policy नसेल तेव्हा fail होणारा CI check जोडा, आणि Git मध्ये data: सह kind: Secret सापडल्यावर fail होणारा secret scanner (धडा 07) जोडा. दोन्ही चुका करायला सोप्या आहेत आणि कोणी त्यांचा वापर करेपर्यंत शांत राहतात.

⏭️ पुढे

Pod कोण तयार करू शकतो हे RBAC ठरवते. त्याच्यापर्यंत कोण पोहोचू शकतो हे NetworkPolicy ठरवते. पण कोणत्या प्रकारचा pod मुळात चालू शकतो — root म्हणून? privileged? host ची disk mount करून? पुढे: pod चालण्यापूर्वीचे दार.

git checkout lesson-12-admission

🕸️ Lesson 11 — Kubernetes secrets & network policies: mirror writing is not a lock

📍 You are here: Lesson 11 of 16 · Previous: lesson-10-k8s-rbac · Next: lesson-12-admission

📦 What's in this branch

Lessons 01–10, plus two surprises that every new cluster has. First: a Kubernetes Secret is only base64 — an encoding, not encryption — unless you turn on encryption at rest or keep the real secret in an external store. Second: every pod can talk to every other pod, until a NetworkPolicy selects it — and only if the cluster's network plugin (CNI) enforces policies. You learn both, and the default-deny pattern.

sec/cloud.py — netpol_allows(policies, src_labels, dst_labels, port)
sec/demo.py — python3 sec/demo.py k8s_network
sec/test_sec.py — check L11

🧒 Explain like I'm 5

The secret envelope. Aishwarya puts the database password in an envelope marked "SECRET". But inside, the password is not locked — it is only written in mirror writing. Anyone who holds a mirror (and everyone has one) can read it. That is base64. To make it really secret, the office must lock the envelope with a key from the key safe (encryption at rest with KMS), or keep the password in the key safe itself and bring it only when needed (an external secret store).

The corridors. In a new school building, every door is open. Any pupil can walk into the staff room, the server room, the kitchen. The office can put a guard on a door with a list: "Only the results helper, and only through the side door number 5432."

Two rules about guards:

A door without a guard stays open to everyone. So the office starts by putting a guard on every door with an empty list — "nobody" — and then adds names. That is default-deny.
The guard list is only paper. If the building has no guard service (a CNI that enforces policies), the paper does nothing, and nobody tells you.

🗺️ Diagram

flowchart LR
    r["🍳 results-api"] -->|"5432 ✓"| pg["📒 postgres<br/>NetworkPolicy: from app=results-api, port 5432"]
    n["📢 notices-api"] -. "5432 ✗" .-> pg
    r -. "22 ✗" .-> pg
    w["🌐 web (no policy selects it)"]
    any["any pod"] -->|"✓ everything allowed<br/>until default-deny"| w
    s["🔑 Secret password: U3VtbWVy…<br/>base64 -d → readable"] --> k["🗝️ encryption at rest (KMS)<br/>or External Secrets"]

🗺️ Drawn version + a lab: https://school-edh.pages.dev/security/lesson-diagrams.html#l11

❓ What

Secret — a Kubernetes object that holds small sensitive values (passwords, tokens, keys). The values are base64-encoded so binary data fits in YAML. Base64 is not encryption: base64 -d reverses it, no key needed.
Where Secrets live — in etcd, the cluster's database. Without encryption at rest, anyone who gets an etcd backup or a disk snapshot can read every Secret.
Encryption at rest for Secrets — the API server encrypts Secrets before writing them to etcd, set up with an EncryptionConfiguration file. The best provider is KMS v2: a key in a cloud KMS wraps the data keys (envelope encryption, lesson 07). On EKS, newer versions add default envelope encryption, and you can choose your own KMS key for Secrets so you control and audit it. Existing Secrets are encrypted only after they are written again.
Who can read Secrets — RBAC (lesson 10) still decides. get/list on secrets, or create on pods in the namespace, is enough to read them. Encryption at rest does not protect against someone the API lets read.
External secret stores — keep the real value in AWS Secrets Manager, SSM Parameter Store or HashiCorp Vault. The External Secrets Operator copies it into a Kubernetes Secret and refreshes it; the Secrets Store CSI Driver mounts it as a file. Rotation happens in one place.
NetworkPolicy — a list of allowed traffic for the pods it selects (by label): ingress (who may come in) and egress (where they may go), by pod labels, namespace labels or IP ranges, and ports.
The two rules that surprise everyone:
- a pod that no policy selects allows all traffic in and out;
- once any policy selects a pod for ingress (or egress), only what some policy allows gets through — policies add up, like RBAC; there are no deny rules.
Default-deny — a policy with podSelector: {} (every pod in the namespace) and no allow rules. Then add small allow policies. Remember DNS: with default-deny egress, pods must be allowed to reach kube-dns on port 53.
The CNI must enforce it — NetworkPolicy is only an API object. Calico, Cilium and the Amazon VPC CNI (with network policy turned on) enforce it. Some plugins (for example plain Flannel) accept the objects and ignore them.

🤔 Why

Because the two defaults point the wrong way for security. An attacker who gets a shell in one pod (lesson 01's injection, a vulnerable library from lesson 13) can then reach the database, the cache, the metrics endpoints and other teams' services — unless a policy stops them. And a Secret that "looks" protected is copied into backups, CI logs and kubectl get -o yaml output in a form anybody can decode. Default-deny plus encrypted, externally managed secrets turn one broken pod into one broken pod — not the whole school.

🔧 How (in this repo)

netpol_allows(policies, src_labels, dst_labels, port) in sec/cloud.py models ingress to a pod:

find the policies whose pod labels all match the destination pod;
if none select it → True (open to everyone);
otherwise → allowed only if some selecting policy's from labels all match the source and the port is in its ports.

An empty pod={} selects every pod, and ports=[] allows nothing — together, a default-deny. k8s_network() in sec/demo.py puts one policy on the postgres pods. The snippet also shows what a Secret value looks like in base64 — using the made-up password from lesson 07's scan.

🧪 Try it

python3 sec/demo.py k8s_network
python3 - <<'EOF'
import sys, base64; sys.path.insert(0, "sec"); from cloud import netpol_allows
deny_all = dict(pod={}, ports=[], **{"from": {}})                                  # selects every pod, allows nothing
db_rule  = dict(pod={"app": "postgres"}, ports=[5432], **{"from": {"app": "results-api"}})
web_rule = dict(pod={"app": "web"}, ports=[8080], **{"from": {"app": "ingress"}})
tries = (({"app": "notices-api"}, {"app": "web"}, 8080), ({"app": "ingress"}, {"app": "web"}, 8080),
         ({"app": "results-api"}, {"app": "postgres"}, 5432), ({"app": "web"}, {"app": "postgres"}, 5432))
for name, pols in (("no policies", []), ("default-deny only", [deny_all]), ("default-deny + 2 allows", [deny_all, db_rule, web_rule])):
    print(f"── {name}")
    for src, dst, port in tries:
        print(f"   {src['app']:<12} → {dst['app']}:{port:<5} {'allowed' if netpol_allows(pols, src, dst, port) else 'blocked'}")
stored = base64.b64encode(b"Summer2026!school").decode()
print(f"── a Secret as the API server stores it: password: {stored}")
print(f"   anyone who can read it runs base64 -d → {base64.b64decode(stored).decode()}")
EOF
python3 sec/test_sec.py

✅ Verify — what you should see

k8s_network prints:

═══ k8s_network ═══
── NetworkPolicy on the database pods: only results-api, only 5432
   results-api  → postgres:5432  allowed
   notices-api  → postgres:5432  blocked
   results-api  → postgres:22    blocked
   pods with no policy selecting them accept everything → True — start every namespace with default-deny
   Kubernetes Secrets are only base64 — enable encryption at rest, or use an external secret store

✅ done — every door checked

Your snippet prints:

── no policies
   notices-api  → web:8080  allowed
   ingress      → web:8080  allowed
   results-api  → postgres:5432  allowed
   web          → postgres:5432  allowed
── default-deny only
   notices-api  → web:8080  blocked
   ingress      → web:8080  blocked
   results-api  → postgres:5432  blocked
   web          → postgres:5432  blocked
── default-deny + 2 allows
   notices-api  → web:8080  blocked
   ingress      → web:8080  allowed
   results-api  → postgres:5432  allowed
   web          → postgres:5432  blocked
── a Secret as the API server stores it: password: U3VtbWVyMjAyNiFzY2hvb2w=
   anyone who can read it runs base64 -d → Summer2026!school

The tests include ✅ L11 a NetworkPolicy lets only the named source in and end with 16/16 passed.

🏁 What you just proved

With no policies, all four connections work — even web → postgres, which nobody wanted. Default-deny alone closes everything (safe, but the app is down). Default-deny plus two small allow rules gives exactly the two paths the school needs, and the other two stay closed. The policies add up: the allows did not have to "remove" the deny. And the "secret" password came back from base64 in one line, with no key.

⚠️ Common mistakes

writing policies on a cluster whose CNI does not enforce them — everything looks fine and nothing is blocked (test with a real connection, see below)
policies for a few "important" pods only — every other pod stays open to everyone
default-deny egress without a DNS allow — every lookup fails and the app looks broken
an ingress allow on the database, but default-deny egress on the API with no egress allow to the database — traffic needs both sides open
selecting pods by a label that some other team's pods also carry (app: api)
Secrets in Git "because they are encoded"; kubectl get secret -o yaml pasted into a ticket
encryption at rest turned on, but old Secrets never re-written, so they are still plain in etcd
believing encryption at rest stops a user whom RBAC allows to get secrets — it does not

🏭 In production

On a real account — default-deny for the namespace, a DNS allow, and the two paths the school needs:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny, namespace: school }
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: allow-dns, namespace: school }
spec:
  podSelector: {}
  policyTypes: [Egress]
  egress:
    - to:
        - namespaceSelector: { matchLabels: { kubernetes.io/metadata.name: kube-system } }
          podSelector: { matchLabels: { k8s-app: kube-dns } }
      ports: [{ protocol: UDP, port: 53 }, { protocol: TCP, port: 53 }]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: postgres-from-results-api, namespace: school }
spec:
  podSelector: { matchLabels: { app: postgres } }
  policyTypes: [Ingress]
  ingress:
    - from: [{ podSelector: { matchLabels: { app: results-api } } }]
      ports: [{ protocol: TCP, port: 5432 }]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: results-api-to-postgres, namespace: school }
spec:
  podSelector: { matchLabels: { app: results-api } }
  policyTypes: [Egress]
  egress:
    - to: [{ podSelector: { matchLabels: { app: postgres } } }]
      ports: [{ protocol: TCP, port: 5432 }]

Prove the CNI enforces it — a throwaway pod with the wrong label must fail, one with the right label must connect:

kubectl -n school run np-test --rm -it --restart=Never --image=busybox:1.36 \
    --labels app=notices-api -- nc -zv -w 2 postgres 5432      # expect: timed out
kubectl -n school run np-test --rm -it --restart=Never --image=busybox:1.36 \
    --labels app=results-api -- nc -zv -w 2 postgres 5432      # expect: open

On EKS with the Amazon VPC CNI, turn policy enforcement on in the add-on configuration ({"enableNetworkPolicy": "true"}), or run Calico or Cilium.

Encryption at rest for Secrets — on a cluster you run yourself, an EncryptionConfiguration passed to the API server with --encryption-provider-config:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources: ["secrets"]
    providers:
      - kms:
          apiVersion: v2
          name: school-kms
          endpoint: unix:///var/run/kmsplugin/socket.sock
          timeout: 3s
      - identity: {}        # only so Secrets written before the change can still be read

Then write every Secret again, so they are stored encrypted:

kubectl get secrets --all-namespaces -o json | kubectl replace -f -

On EKS, choose your own KMS key for Secrets:

aws eks associate-encryption-config --cluster-name school \
    --encryption-config '[{"resources":["secrets"],"provider":{"keyArn":"arn:aws:kms:ap-south-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab"}}]'

External Secrets Operator — the password lives in AWS Secrets Manager; the operator creates and refreshes the Kubernetes Secret results-db:

apiVersion: external-secrets.io/v1
kind: SecretStore
metadata: { name: aws-secrets, namespace: school }
spec:
  provider:
    aws:
      service: SecretsManager
      region: ap-south-1
      auth:
        jwt:
          serviceAccountRef: { name: external-secrets-reader }
---
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata: { name: results-db, namespace: school }
spec:
  refreshInterval: 1h
  secretStoreRef: { name: aws-secrets, kind: SecretStore }
  target: { name: results-db }
  data:
    - secretKey: password
      remoteRef: { key: school/results-db, property: password }

(Older operator releases use external-secrets.io/v1beta1; check the version you run.)

🏭 Why this matters in production: add a CI check that fails when a namespace has no default-deny policy, and a secret scanner (lesson 07) that fails on kind: Secret with data: in Git. Both mistakes are easy to make and silent until someone uses them.

⏭️ Next

RBAC decides who may create a pod. NetworkPolicy decides who may reach it. But what kind of pod may run at all — as root? privileged? with the host's disk mounted? Next: the gate before a pod runs.

git checkout lesson-12-admission

← Previousk8s rbac Next →admission

This page is the lesson's README from the lesson-11-k8s-secrets-network branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.