We close the module with the lesson that fixes the hole we have been dragging along since module 3: any pod in the cluster can connect to bookings-postgres:5432. A compromised pod, a malicious dependency in an image or a misdirected deployment in rutas-norte-dev currently has direct access to the database holding the name, ID number, phone and email of every Rutas Norte customer. NetworkPolicies are the native Kubernetes firewall, and in this lesson we will build the platform's isolation model step by step: deny everything, open DNS —the mistake that takes down the whole cluster and that almost everybody makes once—, and authorise one by one only the conversations the platform needs, verifying each rule with ephemeral pods.

1. Demonstrating the problem: the network is flat
2. The indispensable requirement: a CNI that implements them
3. Anatomy of a NetworkPolicy
4. The additive model: only allow, never deny
5. from/to: podSelector, namespaceSelector and ipBlock
6. The costliest mistake: AND versus OR
7. Step 1: deny everything in rutas-norte-pro
8. Step 2: allow DNS (or break everything)
9. Step 3: the platform's conversations
10. Step 4: the Ingress and the external payment gateway
11. Systematic verification
12. Real limitations

Before fixing anything, let us see it. We launch in production a pod that has no relationship at all with the platform: no Rutas Norte labels, no dedicated ServiceAccount, nothing.

Everything works. It is rule 2 of the network model from 04-01: every pod can talk to every pod without NAT. It is not a bug: it is the specified behaviour. And its implications are serious:

We have already added layers —minimal identity with ServiceAccounts (03-06) and per-environment quotas (03-04)—; the network layer is what is missing.

Here is the silent danger of this lesson. Kubernetes defines the NetworkPolicy object, but it does not enforce it. The one that enforces it is the CNI plugin, and if the plugin does not implement it the object is created with no error and no warning at all, kubectl get networkpolicy lists it as normal, kubectl describe shows the rules perfectly… and the traffic keeps flowing exactly as before. You will have a security policy that protects nothing and a false sense of being covered. As we saw in 04-01, Flannel does not implement NetworkPolicy, and it is the default CNI of a great many lab installations, minikube's included.

An alternative: --cni=cilium, which also gives L7 policies and observability with Hubble. But never trust the plugin's name: verify with a real test (exercise 1). The idea is to create a target pod in a throwaway namespace, check that it answers, apply an ingress deny-all and check that it stops answering; if it keeps answering, your CNI ignores the policies. Always do this on a new cluster, before writing a single real policy.

Three warnings about policyTypes, which is where most mistakes happen: if you omit it, Kubernetes infers it (it always includes Ingress and only includes Egress if there is an egress block), so write it explicitly; policyTypes: [Ingress] with ingress: [] means "deny all inbound traffic", which is different from not having the field; and policyTypes: [Ingress, Egress] with no rules is total isolation. And the key point: a NetworkPolicy is namespaced and its podSelector only looks inside its own namespace. To protect the three environments you need the policies in all three.

The mental model to nail down before writing anything:

Out of that come four golden rules: with no policies, everything gets through (Rutas Norte's state so far); as soon as ONE policy selects a pod in a direction, that pod becomes isolated in that direction and only what is explicitly allowed gets through; policies are additive and there is no "deny" —there is no deny field, the union of all the policies that select the pod defines what is allowed and it takes just one to authorise it—; and there are no priorities and no ordering, no order and no "last one wins".

Practical consequence: you cannot make a restrictive exception. If a policy lets all of rutas-norte-pro reach bookings-postgres, you cannot add another saying "except this pod": you have to remove the broad permission and enumerate the allowed ones. Another confusing detail: ingress and egress are evaluated separately and at both ends, so for bookings-api to talk to bookings-postgres you need two authorisations —the sender's egress and the receiver's ingress— and if either is missing there is no connection; it is the number one cause of "I allowed the traffic and it still does not work". Finally, policies act on connections and the CNIs that implement them track state, so the reply comes back without needing a return rule.

There are exactly three ways of identifying the other end.

A podSelector inside from/to cannot reach other namespaces; that is what the next one is for.

Kubernetes adds to every namespace the label kubernetes.io/metadata.name holding its name, which saves labelling them by hand; even so it is worth adding your own stable labels (kubectl label namespace rutas-norte-pro environment=pro).

Two warnings: it is not for pods —even though a pod IP is technically inside a CIDR, the implementation treats it as external traffic and it is not reliable; for pods, use selectors— and except only subtracts from the cidr of that same block, it is not a global deny. The 0.0.0.0/0 pattern with an except for the private networks is the standard way of saying "it can go out to the internet, but it cannot pivot towards the company's internal network".

This section is the one that prevents the most real security incidents. Let us compare two fragments that differ by a single hyphen:

Version A opens the database to entire namespaces. It is a mistake that slips through code review easily because the YAML looks like it says the opposite, and the cluster gives no warning: the policy is applied and works, it just allows far more than intended. Mnemonic: every hyphen in the from list is an "OR"; the fields inside a single element are an "AND". The same distinction applies to the elements of ingress (a list of rules joined by OR) and to ports inside a rule.

We start with the foundation: close everything, and then open only what is needed, even if the platform is broken for a few minutes.

The platform is completely broken, and that is what we wanted: from here on every rule will be a conscious, documented decision. It is least privilege applied to the network. An important note: kubectl exec, kubectl logs and the kubelet's health probes (07-01) are unaffected, because they come from the node and not from another pod; that is why you can carry on debugging with a completely locked-down cluster.

This is the classic mistake with NetworkPolicies, and it deserves its own section because its symptom is thoroughly misleading. With deny-all in force no pod can talk to CoreDNS, and the bookings-api logs show this:

The symptom is not "connection refused": it is a name resolution failure after several seconds of waiting, failure type 1 from 04-03. The typical confusion is to investigate CoreDNS, which is perfectly healthy, instead of looking at the egress policy just applied. Making it worse: an egress deny-all in kube-system leaves the whole cluster without DNS; never apply broad policies in the system namespaces.

Three details that must be respected:

1. podSelector: {}: every pod needs DNS, without exception. It is always the first rule to be written.
2. UDP and TCP on 53. TCP is forgotten constantly. DNS falls back to TCP when the answer does not fit in a UDP packet, and in a headless Service with many pods that happens: the symptom is devastating, it works nearly always and fails apparently at random.
3. namespaceSelector + podSelector with no hyphen, so that it is the intersection: CoreDNS inside kube-system. With a hyphen you would open all of kube-system. Also check the real label on those pods (kubectl get pods -n kube-system --show-labels | grep dns); in some distributions it is k8s-app: coredns.

We list, one by one, Rutas Norte's legitimate connections:

Nothing else: web-store does not talk to the database (it serves a static SPA), redis-cache initiates no connections and bookings-postgres goes nowhere.

The first one is the policy that justifies the whole lesson: no other pod in the cluster can now even attempt to open a connection to the database holding the personal data. And remember that allow-dns-egress and the second one add up: bookings-api reaches DNS, PostgreSQL and Redis, and nothing else. The egress for notifications-worker is analogous, with PostgreSQL and the corporate mail server.

The controller lives in ingress-nginx, so we need a namespaceSelector:

Two details: the ports are the container's (targetPort), not the Service's, because policies see the real traffic arriving at the pod and kube-proxy already translated the port on the source node (04-01) —putting 80 instead of 8080 produces a 503 at the Ingress that is very hard to connect with a policy—; and the matchExpressions of 02-07 solves the "one or the other" in the podSelector.

It lives outside the cluster, at pagos.proveedorexterno.example: selectors are of no use, we have to use ipBlock.

Delicate points: an ExternalName does not help here, because the payment-gateway Service from 04-02 only creates a CNAME and the real traffic goes to an external IP that must be authorised with ipBlock; policies work with IPs, not with names, so if the provider changes range the connection breaks without warning —use the range they publish and document, not the IP a dig returns today—; DNS is already allowed by the step 2 policy, without which bookings-api could not even resolve the name; and if there are no stable ranges, the alternative is an egress proxy with a per-domain allowlist, or Cilium, with FQDN policies.

Anything not in that diagram is denied.

An unverified policy is an assumption: you have to check both sides.

And the test that makes sense of it all, with the intruder pod from section 1:

Timed out. The hole we had been dragging along since module 3 is closed. Note the detail: it is timed out, not "connection refused", because NetworkPolicies drop packets silently, without sending an RST. That signature is useful for diagnosis:

They are indispensable and also clearly limited. You have to know what they do not do.

What Cilium or a mesh would add in Rutas Norte: allowing only GET /availability and POST /bookings instead of "the whole port 3000"; certificate-based identity, so that creating a pod with app: bookings-api is not enough to impersonate the component; visibility of allowed and denied flows, which turns "this just hangs" into "this specific policy dropped it"; and per-domain policies for the payment gateway.

None of that detracts from what we have built: NetworkPolicies are the base layer and the one any audit demands. The complete strategy is studied in 08-04.

• Writing policies with a CNI that ignores them. They apply without error and protect nothing. Always verify with a real test, not with the plugin's name.
• Forgetting DNS. The first egress deny-all breaks resolution across the namespace and the symptom (EAI_AGAIN) does not point at the policy: the DNS rule is always the first one written. And allowing only UDP on 53 fails intermittently: authorise UDP and TCP.
• The extra hyphen in from. It turns an AND into an OR and opens entire namespaces. Re-read it at every code review.
• Authorising only one direction (you need the sender's egress and the receiver's ingress), or using the Service port instead of the targetPort: policies see the container's port.
• Applying deny-all in kube-system. You can leave the whole cluster with no DNS, no metrics and no Ingress.
• Expecting an explicit "deny" (there is none: to restrict, you must remove the broad permission) or confusing timed out with connection refused: the first smells of a policy, the second of a crashed process.
• Tip: apply the policies in rutas-norte-dev first, run the verification script and only then promote to pre and pro. A badly judged deny-all in production is a total outage.
• Tip: name the files with a numeric prefix (np-00-deny-all, np-01-allow-dns, ...) so that reading order reflects build order.
• Tip: document every policy with the business conversation it authorises. "notifications-worker reads the booking in order to send the email" ages far better than "allows 5432".

Work out which CNI is installed and prove with a practical test —not with the plugin's name— whether NetworkPolicies are enforced. If not, recreate the profile with Calico and repeat.

Apply, in order, deny-all, the DNS rule and the policies from sections 9 and 10, documenting after each step what works and what stops working. When you finish, run the verification script and check that the intruder pod no longer reaches the database.

This policy arrives for you to review. Identify the flaw, explain what it allows beyond the intention and fix it.

Exercise 1

With Flannel the curl will answer (it ignores them); with Calico or Cilium it will time out. If you have to rebuild, minikube delete -p rutas-norte and recreate the profile with --cni=calico.

Exercise 2

Exercise 3

The flaw is the two hyphens in from: the podSelector and the namespaceSelector are different elements of the list, so they combine with OR. What it allows beyond the intention is enormous: any pod, in any namespace labelled environment: pro, can connect to redis-cache:6379. The intention was "only bookings-api" and the result is "the whole production environment"; a compromised pod in any production namespace could read and poison the seat availability cache.

The fix: merge both selectors into a single element (an AND), or simply keep the podSelector, given that the policy already lives in rutas-norte-pro.

You have closed the hole: you started by proving with an intruder pod that without NetworkPolicies the network is flat and that any container in the cluster reaches the database holding the customers' personal data, and you finished with that same test timing out. Along the way you have nailed down what matters most. First, that Kubernetes defines the object but does not enforce it: the CNI does, and a plugin such as Flannel accepts your policies without a single warning and filters nothing, so the only acceptable guarantee is a practical test on every cluster. Second, the additive model: as long as no policy selects a pod, everything gets through; as soon as one does, that pod is isolated in that direction and only what is explicitly allowed gets through; policies add up, there are no priorities and there is no deny, which means restrictive exceptions do not fit. Third, that you need both directions: the sender's egress and the receiver's ingress. And you have mastered the three selectors —podSelector for the same namespace, namespaceSelector for crossing them and ipBlock with except for the outside world— and above all the difference between AND and OR, that extra hyphen which turns "only bookings-api" into "the whole production environment" without the cluster saying a word.

You have built the complete model for rutas-norte-pro in the right order: deny-all first, even though it breaks the platform; DNS next, with UDP and TCP towards CoreDNS, avoiding the classic failure whose symptom (EAI_AGAIN) points everywhere except at the policy you have just applied; and then each business conversation authorised one at a time: bookings-api and notifications-worker towards PostgreSQL, bookings-api towards Redis, the Ingress controller towards the store and the API on their targetPorts, and bookings-api towards the payment gateway via ipBlock. All of it verified from both sides, knowing that a timed out smells of a policy and a connection refused of a crashed process. And you know the limits: L3/L4, no cryptographic identity, no denial logging and no domain names, which is where Cilium or a service mesh come in (08-04).

This brings module 4 to a close and Rutas Norte is for the first time a real, accessible platform. Customers come in through https://www.rutasnorte.example, agencies consume https://api.rutasnorte.example, the certificates renew themselves, discovery between components goes over DNS and the network is segmented so that only the legitimate conversations are possible.

One piece remains, one we have been dragging along since module 2 with a "PROVISIONAL" note in the manifest: bookings-postgres has no persistent storage. Its Deployment keeps the data inside the container, so every restart of the pod —a rollout, an eviction, a node failure— wipes every booking and every customer. Module 5, Storage in Kubernetes, solves exactly that: volumes, PersistentVolumes and PersistentVolumeClaims, storage classes, dynamic provisioning with expansion and snapshots, and backup and restore. It is the module that turns Rutas Norte into a platform you can trust.