Lock down a shop namespace

One hurried NetworkPolicy lets every pod in every namespace reach the API, and nothing protects the web tier or the database. Rewrite the shop namespace’s policies so only the flows the application needs are allowed.

Requires Node.js 22 or newer. No package installation or server needed. To work in a container instead, open the folder with VS Code Dev Containers or GitHub Codespaces: .devcontainer/devcontainer.json uses the Dev Containers Node.js 24 image, pinned by digest.
1. Unzip all files into one folder.
2. In that folder, run: node --test exercise.test.mjs
3. Edit shop-policies.mjs, then run the same command again.

The starter deliberately fails some tests. A successful repair passes every case, including cases that catch common wrong fixes. The browser runs this same cases.mjs with the same fixtures; locally Node runs your code directly. If you completed the optional first stage in the browser, Download my work adds your input as stage1-input.json and the tests include it. Only run code you wrote or reviewed.

1. Reproduce the open paths
Run the starter. Its single peer list says “any pod in any namespace” OR “web pods in shop”, so sandbox pods reach the API, and because nothing selects web or the database, every pod in the cluster can reach them.

2. Deny by default
Add a policy with podSelector: {} and policyTypes: ["Ingress"] in shop. It selects every pod in the namespace and allows nothing, so each pod now accepts only what another policy allows.

3. Allow each flow with both selectors in one peer
For a source in another namespace, put namespaceSelector (on kubernetes.io/metadata.name) and podSelector in the same from entry: one entry means AND, two entries mean OR. A podSelector on its own means pods in the policy’s own namespace. Name the TCP port in every rule.

4. Shut the database’s egress
A policy that should block all egress must say policyTypes: ["Ingress", "Egress"]; an empty egress list without it defaults to Ingress only. Check that the ordinary flows still work: the controller to web, web to api, Prometheus to the metrics port and api to the database.

SUPPLIED CONTRACT
shopNetworkPolicies() returns an array of NetworkPolicy objects (apiVersion networking.k8s.io/v1, kind NetworkPolicy, metadata with name and namespace, and a spec), the same objects kubectl apply would take as YAML. The grader evaluates them as Kubernetes does: a pod is isolated for ingress or egress only when a policy in its namespace selects it with that policy type; policies add up, so a connection is allowed when any applicable policy allows it; and a connection needs the source’s egress and the destination’s ingress. When policyTypes is missing it means Ingress, plus Egress only when the policy has egress rules. Pods: shop/web-1 (app=web, TCP 8080), shop/api-1 (app=api, TCP 8080, metrics on 9090), shop/db-0 (app=postgres, TCP 5432) and shop/debug-7 (app=debug); ingress-nginx/controller-1 (app.kubernetes.io/name=ingress-nginx); monitoring/prometheus-0 (app=prometheus) and monitoring/grafana-0 (app=grafana); sandbox/web-x (app=web) and sandbox/prometheus-x (app=prometheus). The sandbox team labelled its namespace purpose=monitoring; select namespaces by the kubernetes.io/metadata.name label, which Kubernetes sets to the namespace’s name. Required: every shop pod refuses ingress unless allowed below; web accepts TCP 8080 only from the ingress controller; api accepts TCP 8080 from shop’s web and TCP 9090 from monitoring’s Prometheus; the database accepts TCP 5432 only from shop’s api and makes no outbound connections at all.

REFERENCE
reference.mjs contains an explained solution: Allowed: ingress-nginx/controller-1 to web on 8080, shop/web-1 to api on 8080, monitoring/prometheus-0 to api on 9090 and shop/api-1 to the database on 5432. Refused: sandbox/web-x to api (a web label in another namespace), sandbox/prometheus-x to api on 9090 (a namespace labelled purpose=monitoring by its own team), monitoring/grafana-0 to api on 9090, Prometheus to the database, web, debug and the ingress controller to the database or straight to api, web to the metrics port, Prometheus to api on 8080, sandbox and debug pods to web, UDP to the database, and any connection from the database, to api or to 203.0.113.10:443.

SCOPE
The grader evaluates the policy objects; a real cluster enforces them only when its network plugin supports NetworkPolicy, so prove each rule with live connections as the guide shows. The model has no Services, node or hostNetwork traffic, and gives pods no IP addresses, so ipBlock matches only the external host. Restricting egress for the other shop pods also needs DNS on UDP and TCP port 53 to the cluster DNS pods. NetworkPolicy works at layers 3 and 4: it does not authenticate the caller or authorize a request, and labels used in selectors need protecting through RBAC and admission control. The OWASP Kubernetes Top 10 (2025) lists this risk as K05, Missing Network Segmentation Controls.

NEXT TASK
Pick a namespace you run. Which pods does no NetworkPolicy select today, and which policy, if someone added it tomorrow, would reopen your database to the whole cluster?

SOURCE
https://kubernetes.io/docs/concepts/services-networking/network-policies/
