The shop namespace now has a default-deny policy for both directions. The frontend calls the api at /api/orders, Traefik sends outside traffic to the frontend, and every Pod needs DNS.
About this scenario
The shop namespace now has a default-deny policy for both directions. The frontend calls the api at /api/orders, Traefik sends outside traffic to the frontend, and every Pod needs DNS.
Write policies so that http://shop.example.com/api/orders works again, while the intruder Pod in the other namespace still can't reach the api.
Objectives
- DNS works again in the shop namespace
- http://shop.example.com/api/orders returns the orders
- The intruder Pod in namespace other still can't reach the api
- The default-deny policy is still there
What you'll practice
- Policies only add allowed traffic. With default-deny in place, every connection needs a rule on both ends: egress from the client and ingress to the server.
- Default-deny egress also blocks DNS, which shows up as
bad addressorCould not resolve host, not as a timeout. - Traffic through an Ingress comes from the controller's Pods, so the policy must allow the controller's namespace.
How the playground works
The cluster runs entirely in your browser: a simulated API server, scheduler, kubelets and controllers, with virtual nodes in three zones. kubectl output follows the real formats, errors use the real messages, and the add-ons (CSI storage, Traefik, Envoy Gateway, cert-manager, Flux, Argo CD) behave like their real counterparts for the common paths. It's a simulation, so some behavior is simplified. Your progress is saved in this browser.