We have closed two dimensions of Rutas Norte's security. With RBAC (08-01) we control who can do what against the API. With security contexts (08-02) and admission policies (08-03) we control what a container can do once it is running, and we got the cluster to enforce it on its own.

An entire dimension remains: what can talk to what. And here we already did important work in 04-06, when we put a deny-all NetworkPolicy in rutas-norte-pro and authorised each conversation one at a time. But we then pointed out three uncomfortable limits that we parked:

1. NetworkPolicies work at L3/L4: they understand IPs and ports, not HTTP paths or methods. bookings-api can reach bookings-postgres, yes, but the policy does not distinguish a legitimate query from a full dump of the customer table.
2. They log nothing. A denied connection attempt is completely invisible. If somebody is probing the internal network, we never find out.
3. Inside the cluster, all traffic travels unencrypted once past the Ingress TLS (04-05). Whoever can observe the node's network sees the queries to bookings-postgres in the clear, with names, ID numbers and phone numbers included.

And there is a fourth thing we have barely mentioned: outbound traffic. It is the natural route by which a customer database leaves.

This lesson does not repeat the NetworkPolicy syntax: it takes it as known and uses it. What we build here is the complete network strategy of a production platform, layer by layer.

Important warning. The network architecture design of a production platform must be reviewed by a security professional, who will assess the specific threat model. And since Rutas Norte's traffic carries customers' personal data —name, ID number, phone and email—, the decisions about encryption in transit, egress control and flow logging must also be known and approved by the compliance officer. This lesson's approach is exclusively defensive: understanding the paths by which information can leak in order to close them and detect them.

1. The network defence layers
2. Microsegmentation as a principle
3. Egress traffic control
4. The IPs versus domain names problem
5. Encryption in transit inside the cluster
6. What a service mesh is and what it costs
7. Istio, Linkerd and Cilium compared
8. Layer 7 authorization policies
9. Protecting the perimeter
10. Control plane security
11. Traffic logging and visibility
12. Zero trust applied to Rutas Norte
13. Common mistakes and tips
14. Exercises
15. Conclusion

Network security is not one mechanism: it is a series of layers, each of which assumes the previous one can fail. This is the complete model we are going to build.

The order matters: each layer is justified by what would happen if the previous one failed. If the WAF does not stop an attack, the Ingress still validates the certificate. If somebody manages to run code in web-store, microsegmentation stops them reaching bookings-postgres. If they did get there, mTLS would stop them passing themselves off as bookings-api. And if everything above failed, egress control would stop the data leaving the cluster.

Microsegmentation means treating each workload as its own network segment, with explicit rules about what can talk to what. It is the opposite of the traditional "trusted internal network behind a firewall" model.

In a classic network, the firewall separated "inside" from "outside", and inside everybody talked to everybody. In a Kubernetes cluster, by default, every pod can talk to every pod in every namespace. A curl from web-store reaches bookings-postgres with no obstacle.

Remember what we said in 02-06: a namespace is not a security boundary on its own. Without NetworkPolicies, rutas-norte-dev and rutas-norte-pro are on the same flat network.

The practical consequence: if somebody manages to run code in web-store —the most exposed component, because it faces the internet directly— they have network access to the whole platform. Microsegmentation turns that into "they have network access to bookings-api, and only to port 8080".

Principle 1: deny by default in all three environments.

In 04-06 we applied deny-all in rutas-norte-pro. That is not enough. rutas-norte-dev and rutas-norte-pre need it too, for two reasons:

• If development and pre-production are open, a policy that works there can fail in production, and the failure is discovered at the worst moment.
• A compromised pod in rutas-norte-dev with no network restrictions can reach rutas-norte-pro, because the cluster network is flat.

In 08-03 we solved this elegantly with a Kyverno policy that generates the deny-all in every new Rutas Norte namespace, with synchronize: true so that it comes back if somebody deletes it. It is the guarantee that no future namespace is born open.

Principle 2: policies per component, not per namespace.

It is tempting to write "everything in rutas-norte-pro can talk to everything in rutas-norte-pro". That is a mistake: it reproduces inside the namespace the very flat model we wanted to avoid.

The difference is enormous and the cost is writing six policies instead of one.

Principle 3: periodic review of which conversations are still needed.

Network policies decay just like RBAC. A permission is added to debug something and it stays. A component is retired and its policy survives. A port is changed and the old one is left "just in case".

Rutas Norte's authorised communications matrix, as it stood in 04-06, must fit in one table and be reviewed every quarter:

Each row must have a living reason. A useful question in the review: if I delete this rule right now, what breaks? If nobody knows, find out (in pre-production) or remove it.

A script to detect orphaned policies:

That policy outlived the component it protected. It is not dangerous in itself, but it is noise that makes review harder, and if tomorrow somebody deploys something with that label it inherits permissions nobody decided on.

Here is, probably, the most serious gap left in Rutas Norte.

Think about the sequence of an incident:

1. Somebody finds a flaw in bookings-api and manages to run code.
2. The process has legitimate access to bookings-postgres: it can read the customer table with names, ID numbers, phone numbers and emails.
3. Now it needs to get that data out of the cluster.

Step 3 is what turns a compromise into a data breach. With no egress control, step 3 is trivial: an HTTPS request to any server on the internet.

A rule to internalise: the ingress policy limits who gets in; the egress policy limits what can get out. Almost everybody writes the first and forgets the second. And the second is what decides whether an incident stays as "somebody ran code" or escalates to "the personal data of 200,000 customers was leaked".

Most NetworkPolicy guides only talk about Ingress. Check your policies: if policyTypes does not include Egress, outbound traffic is wide open.

Let us audit which outbound flows are legitimate:

Four of the six components do not need to reach the internet at all. That is the first thing to take advantage of: closing their egress completely is free and removes the exfiltration route for most of the platform.

Recalling that in 04-06 we left deny-all with policyTypes: [Ingress, Egress], each component explicitly needs its own egress. The universal minimum is DNS:

Without this, no pod resolves names and everything fails in a very confusing way: services cannot find each other even though the ingress policies are correct. It is the most frequent mistake when enabling Egress for the first time.

bookings-api needs to reach pagos.proveedorexterno.example. This is where the problem of the next section appears, but let us first see the solution with ipBlock:

The important thing about this manifest is not what it allows, but what it does not allow: bookings-api cannot connect to any other address on the internet. If somebody manages to run code there and wants to send the customer table to a server of their own, the connection does not get out.

A note about ipBlock and private IPs: ipBlock refers to network IPs, and the cluster's pods have IPs too. An ipBlock: 0.0.0.0/0 would include all the cluster's internal traffic. When you want "the whole internet except the internal network", you have to use except:

This is "any public destination on 443", which is far laxer than the provider's range list and we do not recommend it for bookings-api. We include it because it is a pattern that comes up often and it is worth understanding why it is worse: it allows sending data to any server on the internet that speaks HTTPS.

Remember from 06-04 that the connection with the payment gateway goes through an ambassador container inside the bookings-api pod. That has an important network consequence: since the containers in a pod share the network namespace, the policy applies to the whole pod, not to the container. The ambassador and the main container have exactly the same network permissions.

The ambassador brings other advantages —it centralises retries, timeout logic and the gateway credentials— but it is not a network security boundary. If we wanted only the ambassador to be able to talk to the gateway, it would have to be a separate pod with its own policy.

It is a good example of a common confusion: the ambassador pattern is an architecture pattern, not an isolation one.

Here comes the structural limitation of NetworkPolicies.

Standard Kubernetes NetworkPolicies work with IP addresses and CIDR ranges. They know nothing about domain names. There is no to: dnsName: pagos.proveedorexterno.example field.

And this is not an oversight: policies are translated into firewall rules in the node's kernel, which acts on IP packets. By the time the packet gets there, the name has already been resolved and no trace of it remains.

Problem 1: IPs change. Cloud services rotate addresses. The payment provider's documentation may publish ranges today and change them in three months. If your ipBlock falls out of date, payments stop working and the diagnosis is especially thankless because nothing in the logs says "a NetworkPolicy blocked this".

Problem 2: a range is more than you want. 203.0.113.0/24 is 256 addresses. If the provider shares infrastructure, that range may include servers belonging to other customers of theirs. You have authorised egress to 256 destinations in order to reach one.

Problem 3: the reverse scenario is worse. If a legitimate service shares an IP with a generic storage service (something common in public clouds), authorising the first authorises the second, and there you really do have an exfiltration route.

It is the most portable option and the one that gives the best visibility. A Squid or a dedicated proxy in a pod, with a list of domains:

The applications are configured with HTTPS_PROXY, and the NetworkPolicy only allows egress to the proxy:

The decisive advantage: the proxy logs every destination requested, allowed or denied. That partly solves the NetworkPolicies' lack of logging, at least for outbound traffic, which is the one that matters most to watch.

An honest drawback: an application that ignores the HTTPS_PROXY variables bypasses the proxy. That is why the NetworkPolicy is still necessary: it prevents direct egress, forcing traffic through the proxy even if the application does not cooperate. The two layers together work; neither one on its own.

If the CNI is Cilium, the CiliumNetworkPolicy lets you write the name directly:

How it works: Cilium intercepts the pod's DNS responses, sees which IP pagos.proveedorexterno.example returned and dynamically programs the rule for that IP, with the time to live the DNS record indicates. If tomorrow the provider changes IP, the policy keeps working without anyone touching anything.

It is by far the most elegant solution. Its cost is the dependency on the CNI: adopting Cilium is a platform decision that goes well beyond this one policy.

A two-stage approach:

1. Now: ipBlock with the ranges published by the provider, plus a monthly scheduled job that verifies they are still valid and warns if they change. It is the solution that works with any CNI and requires no new pieces.
2. In the medium term: an egress proxy with an allow list, mainly for the destination logging. If at some point we migrate to Cilium (which would also bring the advantages of section 11), the policies are replaced with toFQDNs.

And the check that must be automated in any case:

This test must run in rutas-norte-pre on every deployment. It is the verification of the layer that prevents a personal data breach, and as such it should be in the file the compliance officer reviews.

In 04-05 we put TLS on the Ingress with cert-manager: the traffic between the customer's browser and the platform is encrypted as far as https://www.rutasnorte.example. Perfect. But what happens after the Ingress?

Everything to the right of the Ingress travels unencrypted over the cluster network. And through that stretch, in the clear, pass:

• The SQL queries with customers' names, ID numbers, phone numbers and emails.
• The API responses with the booking data.
• The database credentials, in the initial handshake of every connection.

This is the question that decides whether the effort is worth it:

Notice how the lessons connect: in 08-02 we forbade hostNetwork and CAP_NET_RAW, and in 08-03 we made the cluster reject them. That work is what makes unencrypted internal traffic an acceptable risk in many scenarios. Internal encryption is the defence for when that layer fails, or when regulation explicitly requires it.

It is what we already do with the payment gateway (the ambassador speaks HTTPS). For internal traffic it would mean configuring PostgreSQL with ssl = on, generating certificates, distributing them and configuring every client.

Advantage: it encrypts the stretch that matters most (the personal data) with little rollout. Drawback: it has to be done component by component, you have to manage certificate rotation and trust that each client actually verifies the certificate (many database clients, by default, do not).

For Rutas Norte, encrypting the bookings-postgres connection specifically is a high-value, moderate-cost measure, and probably the first step to take.

Several CNIs can automatically encrypt all traffic between nodes with WireGuard or IPsec.

That last point is the essential limitation: CNI encryption protects against whoever observes the network between nodes, but it provides no per-service identity. web-store and bookings-api on the same node talk just as much in the clear, and neither can cryptographically prove who it is.

Even so, the value-to-effort ratio is excellent. If the CNI supports it, turn it on.

That is the next section, because it gives much more than encryption.

A service mesh is an infrastructure layer that takes care of service-to-service communication, moving it out of the application code.

In the classic model, a sidecar proxy (usually Envoy) is injected into each pod. All the traffic entering and leaving the pod goes through that proxy, which is what applies the encryption, the authorization and the metrics collection. The application never notices: it still does http://bookings-api:8080.

Per-workload identity is the crown jewel and deserves to be understood properly. Without a mesh, when bookings-postgres receives a connection from an IP, all it knows is that it comes from that IP. With the NetworkPolicy we know that IP corresponds to a pod with the app: bookings-api label... but labels are set by whoever creates the pod, and an IP can be spoofed.

With mTLS, bookings-postgres receives a certificate saying spiffe://cluster.local/ns/rutas-norte-pro/sa/bookings-api, signed by the cluster's certificate authority, which nobody else can forge. That is identity. And it fits perfectly with the ServiceAccounts of 03-06.

This is the part the vendor presentations skate over:

That last point has a direct example at Rutas Norte: the occupancy-reports CronJob finishes its work, but the sidecar keeps running and the Job is never marked as complete. There are solutions (native sidecar containers since 1.29, or calling the proxy's termination endpoint), but it is exactly the kind of unforeseen friction that shows up.

Let us answer honestly, because it is an expensive decision.

Arguments in favour:

• It carries personal data between services and internal encryption is defensible in any serious risk analysis.
• L7 authorization would allow rules like "only web-store may do POST /bookings", which NetworkPolicy cannot express.
• Cryptographic identity eliminates service impersonation.

Arguments against:

• There are six components. A mesh shines with dozens or hundreds of microservices and complex communications.
• The call graph is almost linear: web-store → bookings-api → bookings-postgres/redis-cache. There is no topology that justifies a routing layer.
• The platform team is small. Adding a badly operated mesh can worsen security (expired certificates, misunderstood policies, deferred upgrades).
• A good part of the benefit can be had more cheaply: CNI encryption for transit, TLS in PostgreSQL for what is critical, and strict NetworkPolicies for segmentation.

Decision for Rutas Norte: no, not yet. The alternative plan:

1. Enable the CNI's WireGuard encryption (one configuration option).
2. Configure TLS on bookings-postgres, which is where the personal data lives.
3. Keep the strict NetworkPolicies with egress control.
4. Review the decision when any of these objective criteria is met: more than fifteen services, communication between several teams that do not coordinate, an explicit regulatory requirement for mTLS, or a real need for percentage-based canary deployments.

And a general recommendation that goes beyond this course:

A service mesh is an excellent answer to a problem you have to have first. Adopting it "because it is modern", without the complexity that justifies it, adds operational risk without adding net security. If you operate it badly, it is worse than not having it.

That said, you have to know it, because the day the platform grows it will be the right answer. Let us look at the options.

Istio in sidecar mode if you need the most complete feature set: sophisticated routing, complex multi-cluster, API gateway integration, WebAssembly extensions. It is the option with the most capability and also the most expensive to operate. You need dedicated people.

Istio in ambient mode is the evolution that tackles the main criticism of the sidecar model: the per-pod cost. Instead of a proxy in every pod, there is a per-node agent (ztunnel) providing mTLS and L4, and an L7 proxy (waypoint) is deployed only where layer 7 authorization is genuinely needed. It reduces consumption enormously and removes the problem of Jobs that never finish. If we had to choose Istio today, it would be this mode.

Linkerd if you want mTLS and observability with minimum complexity. Its Rust proxy is remarkably lightweight and its philosophy is to do few things and do them well. For a platform like Rutas Norte, if a mesh were ever needed, this would be the first candidate: it covers what we need (mTLS, identity, basic authorization) without Istio's surface area.

Cilium Service Mesh if you already use Cilium as your CNI. By integrating the mesh into the CNI you avoid a whole layer: mTLS and L4 policies are applied in eBPF, inside the kernel, with no proxy. Envoy is only deployed for the L7 policies. It is the most efficient option, and it also brings the domain-name policies from section 4 and the Hubble visibility from section 11. The trade-off is that it ties the mesh decision to the CNI decision.

This is the specific gap NetworkPolicy cannot fill, and it is worth seeing with a real example.

Our current policy says: web-store may connect to bookings-api on port 8080. That is all it can express. As soon as the connection is open, web-store can do:

An L7 policy can tell the difference. Let us see how it would be expressed with Istio, taking the example from the statement: only bookings-api may do POST /bookings.

With action: ALLOW, anything that matches no rule is denied. It is the same default-deny principle as the NetworkPolicies, now applied to HTTP methods and paths.

Look at the key line:

That is neither a label nor an IP: it is the SPIFFE identity the mesh verifies cryptographically in the mTLS handshake. A pod cannot claim that identity without holding the corresponding private key. And note that it is based on the ServiceAccount, closing the circle with 03-06 and 08-01: the ServiceAccount goes from being only the identity before the API to also being the identity before the other services.

The two are complementary, not alternatives. The NetworkPolicy is the first line and the cheapest; the L7 policy is the fine tuning. If you had to keep only one, keep the NetworkPolicy: without it, the L7 policy protects a service anyone can still connect to by other routes.

Without a mesh, L7 authorization is done by the application itself. bookings-api can validate in its own code who is calling it:

It works and for six services it is perfectly reasonable, but it has real drawbacks: it must be implemented in every service, the tokens have to be rotated by hand, and if somebody reads the Secret (RBAC, 08-01) they can impersonate the service. The mesh's mTLS solves all three automatically. It is exactly the kind of cost that grows with the number of services and that, at some point, justifies the mesh.

Everything above protects the inside. Now, the front door.

In 04-02 we looked at the Service types. Let us go over their security implication:

Why NodePort is no good in production:

• It opens the port on every node, including those not running the pod.
• It bypasses the Ingress, and with it the TLS (04-05), the WAF and the rate limiting.
• The port is in a high, unconventional range, hard to protect with a conventional firewall.
• It has no name: anyone who reaches the node's IP reaches the service.

And remember from 08-02 that hostPort is worse still, because there is not even a Service in front.

The Rutas Norte rule: a single entry point, the Ingress load balancer. Everything else is ClusterIP.

A single LoadBalancer, the Ingress one. Any other line in that output is a question that has to be answered.

A web application firewall (WAF) inspects the HTTP requests and blocks known attack patterns: SQL injection, cross-site scripting, directory traversal. With ingress-nginx you can enable ModSecurity with the OWASP rule set:

A serious warning about WAFs: a badly tuned WAF blocks legitimate requests. If web-store can no longer create bookings because a WAF rule considers a name with an apostrophe suspicious, you have created an incident. The correct procedure is identical to the PSA one in 08-03:

1. SecRuleEngine DetectionOnly: log but do not block.
2. Analyse the false positives over weeks of real traffic.
3. Tune the problematic rules.
4. Only then, SecRuleEngine On.

And the rate limiting, via an Ingress annotation:

The headers, one by one:

One detail about HSTS: max-age=31536000 is 365 days, and browsers remember it. If one day your TLS stops working, customers who have already visited the site will not be able to fall back to HTTP. That is what you want from a security standpoint, but you have to be aware of it before enabling it.

An important point that gets forgotten: autoscaling is not a defence against denial of service, it is a way of paying for it. If bookings-api scales to 50 replicas under an attack, you have turned an outage into an invoice. The HPA's upper limit (09-01) is also a security and cost control.

Everything above protects the workloads. The control plane is the highest-value target: whoever controls it controls the whole cluster.

A private IP is a good sign. If you saw a public IP with no source restriction, that is a first-order security finding.

On managed Kubernetes (10-06), all three major providers allow restricting access to the endpoint. It is one of the first things to configure on a new cluster.

etcd stores all the cluster's state, Secrets included. As we said in 03-02, if etcd is not encrypted, the Secrets are in the clear on disk.

Encryption at rest:

An important detail: the order of the providers matters. The first is used to write; all of them are used to read. Having identity: {} at the end allows reading the objects written before encryption was enabled. And after enabling it, they have to be rewritten:

Without that step, the old Secrets stay in the clear in etcd forever.

Other etcd controls:

That point about the backups is easy to overlook and very serious. In 05-06 we talked about Velero and personal data; an etcd backup also contains every credential in the cluster. It must be encrypted, stored with restricted and logged access, and its restore tested periodically.

Every node runs a kubelet with an API on port 10250. Unprotected, it allows listing pods, reading logs and executing commands in any container on that node.

A check:

And a NetworkPolicy or firewall rule stopping pods from reaching the nodes' port 10250 is a very worthwhile defence, because it closes a known escalation route.

Remember from 08-01 that the get nodes/proxy permission is critical precisely because of this: it allows talking to the kubelet and, through it, executing in any pod on the node.

The control plane nodes must not run application workloads. Kubernetes achieves this with a taint (06-05):

That taint stops ordinary pods being scheduled there. The reason is direct: a pod on a control plane node is one flaw away from the cluster's certificates and the etcd database.

And you have to verify that nobody has tolerated it out of convenience:

Only system components that legitimately run on every node. If a rutas-norte-pro pod appeared here, you would have to investigate why that toleration was added. Beware the universal toleration (operator: Exists with no key): it tolerates every taint, the control plane one included, and it often gets added without anyone noticing.

We come back to the second limit we pointed out in 04-06: NetworkPolicies log nothing.

When a NetworkPolicy denies a connection, the packet is dropped in the kernel. There is no Kubernetes event, no log, no metric. From the source pod, the connection simply times out.

The consequences are two, and both are bad:

For operating: debugging "why does my service not connect" is painful. It could be DNS, a policy, a misconfigured Service or the application. Nothing tells you which.

For security: if somebody compromises a pod and starts probing the internal network, they will generate dozens of denied connections and nobody will notice. The clearest signal of lateral movement is precisely the one that is invisible.

Hubble, Cilium's observability component, solves this by taking advantage of the fact that Cilium already inspects every packet in eBPF.

Watching flows in real time:

And what really matters, the denials:

Read it carefully, because that output tells a complete story. web-store —the most exposed component— has tried, within five seconds, to: connect to the customer database, connect to the cache, reach the internet over HTTPS and reach the internet over SSH. web-store does none of that in normal operation. It is exactly the pattern of somebody exploring what they can reach from a compromised pod.

The policies did their job: everything DROPPED. But without Hubble, this would have gone completely unnoticed.

Hubble exposes Prometheus metrics, so it integrates directly with module 7:

That second alert is one of the most valuable on the whole platform: it warns of a possible personal data exfiltration in progress. The route to Alertmanager and its routing are those of module 7; the only new thing is the metric source.

For Rutas Norte, with no Cilium today, the practical combination is: the egress proxy log for external traffic (which is the critical one) and Falco for anomalous connections, which we will see in the next lesson.

Zero trust is a model that can be summed up in one phrase: never trust, always verify. Nothing is considered trusted because of where it sits on the network.

The idea of assuming compromise is the one that changes the design most. It is not about "how do I stop them getting in", but "when they get in, what can they do and how quickly do I find out?".

The three priorities that come out of this table, in order: egress control, traffic visibility and control plane review. All three attack the same scenario: somebody is already inside.

Writing only Ingress policies. If policyTypes does not include Egress, egress is open and with it the exfiltration route. It is the most serious and most frequent mistake in this lesson.

Enabling Egress and forgetting DNS. Everything stops working in a very confusing way: names do not resolve and it looks like a Service problem. The rule towards kube-dns on port 53, UDP and TCP, is the first one to write.

Using ipBlock: 0.0.0.0/0 with no except. It includes the cluster's internal network, so the policy is far more permissive than it looks.

Trusting that an external provider's ipBlock ranges do not change. They change. Schedule a monthly verification or use a proxy with a domain list.

Believing that the ambassador container isolates the network. It shares the network namespace with the rest of the pod. It is an architecture pattern, not a security boundary.

Writing policies per namespace instead of per component. It reproduces the flat network inside the namespace. The cost of doing it properly is five more policies.

Leaving rutas-norte-dev and rutas-norte-pre without policies. The cluster network is flat between namespaces, and a policy only tested in production is tested at the worst moment.

Adopting a service mesh without needing one. It is critical infrastructure: badly operated, it worsens security. Define objective criteria for revisiting the decision.

Enabling a WAF straight into blocking mode. It will block legitimate requests and you will have an incident. DetectionOnly first, weeks of analysis, and then blocking.

Using NodePort in production "because it is quicker to configure". It bypasses the TLS, the WAF and the rate limiting, and it opens the port on every node.

Forgetting that autoscaling does not defend against denial of service. It turns an outage into an invoice. Put an upper limit on the HPA.

Encrypting etcd and not rewriting the existing Secrets. The old ones stay in the clear. kubectl get secrets -A -o json | kubectl replace -f -.

Not encrypting the etcd backups. An etcd backup contains every Secret in the cluster.

Universal tolerations. An operator: Exists with no key tolerates every taint, the control plane one included, and it usually gets added without anyone noticing.

Golden tip: draw the diagram of what talks to what and check that the policies reproduce it exactly, not one arrow more. Then ask the key question: if they compromise this pod, where can they reach and how can they get the data out? If the answer to the second part is not "nowhere", there is outstanding work on egress.

Four of Rutas Norte's six components do not need to reach the internet: web-store, bookings-postgres, redis-cache and occupancy-reports. Write a single NetworkPolicy that allows them only what is indispensable inside the cluster and closes their internet egress completely.

Bear in mind that:

• All of them need DNS.
• bookings-postgres and occupancy-reports must be able to talk to each other (the CronJob queries the database).
• web-store must be able to reach bookings-api.
• All of them must be scrapeable by Prometheus.

Include the command that would verify that egress is effectively closed.

Rutas Norte's management proposes deploying Istio "because it is what the big companies use". Prepare a one-page technical response that includes:

1. What concrete problems it would solve on the current platform.
2. What it would cost, quantified.
3. What cheaper alternatives cover part of the benefit.
4. Objective, measurable criteria for revisiting the decision.
5. A clear recommendation.

At 03:47 the AnomalousDeniedConnections alert fires. You query Hubble and get:

1. What is happening? Justify your reading line by line.
2. Which defence layers worked and which did not?
3. List the immediate actions, in priority order.
4. What would have happened without egress control? And without Hubble?

Solution 1

And the ingress policy so that Prometheus can scrape metrics (it is Ingress, complementary):

An important observation about the first policy: by using a podSelector with matchExpressions that groups four components, they all share the same egress rules. That means redis-cache technically could connect to bookings-api:8080, even though it does not.

It is a conscious trade-off between concision and precision. The strictly correct version would be one policy per component, and that is what we would recommend in production, following principle 2 of section 2. This grouped version is acceptable because the exercise's stated objective —closing internet egress— is met all the same, and none of the extra internal permissions granted gives access to personal data. Documenting that reasoning is as important as the YAML.

Verification:

Checking DNS is as important as checking the block: an egress policy that blocks the internet and DNS breaks the platform without it being obvious why.

Solution 2

Technical report: adopting a service mesh on the Rutas Norte platform

1. What problems it would solve

Of six problems, one is urgent (encryption) and five are desirable improvements with no urgency.

2. Quantified cost

With Istio in ambient mode or with Linkerd, the memory and the latency would drop substantially. The operational complexity and the risk of the first months would not.

3. Cheaper alternatives

The first two together cover 80% of the security benefit for less than 5% of the cost.

4. Objective criteria for revisiting the decision

The evaluation will be reopened when any of these is met:

• The platform exceeds 15 services that communicate with each other.
• More than three teams deploy to the cluster without daily coordination.
• An explicit regulatory or contractual requirement for inter-service mTLS appears (for example, a certification from a corporate customer).
• Percentage-based canary deployments are needed that cannot be approximated with replicas.
• Routing between several clusters is needed (11-05).
• The platform team reaches 5 people or more, with capacity to dedicate one to the mesh.

5. Recommendation

Do not adopt a service mesh now. Instead, in this order:

1. Enable WireGuard in the CNI (this week).
2. Configure TLS on bookings-postgres (this quarter).
3. Roll out flow visibility (this quarter).
4. Review the decision every six months against the criteria above.

If it is adopted in the future, the first candidate would be Linkerd for its benefit-to-complexity ratio, or Istio in ambient mode if by then advanced routing is needed.

Final note: this recommendation is an architecture assessment based on the current size and topology. It must be validated by the organisation's security professional, especially regarding the encryption of traffic carrying personal data, where the compliance officer has the final word on what level of protection is required.

Solution 3

1. What is happening, line by line

The complete sequence —four seconds, three different ports towards the same external IP, probing of internal services, and back to the database— corresponds to no legitimate behaviour of notifications-worker. The signature is that of a compromised process looking for a way to get information out, and the last line suggests it is still accessing data.

An important timing detail: it is 03:47. The occupancy-reports CronJob runs at 03:00. Any connection will have to be ruled out.

2. Layers that worked and that did not

3. Immediate actions, by priority

The commands for the first two steps:

By removing the app label, the ReplicaSet notices it is a replica short and creates a fresh, clean pod: the service recovers on its own while the compromised pod is isolated for analysis. It is a technique worth rehearsing before you need it.

4. The counterfactual scenarios

Without egress control: the three connections to 192.0.2.55 would have been FORWARDED. The process had legitimate access to bookings-postgres, that is, to the customer table with names, ID numbers, phone numbers and emails. This would have been a consummated personal data breach, with an obligation to notify the supervisory authority and the individuals affected. The egress policy —those lines of YAML almost nobody writes— is the only thing that separated a contained incident from a data breach.

Without Hubble: there would have been no alert. Denied connections are silent: with no flow logging, the compromised pod would have carried on querying the database indefinitely, and sooner or later it would probably have found a way out (a changed configuration, a new permission, a badly reviewed policy). The incident would have been discovered weeks or months later, or never.

This exercise sums up the whole lesson: prevention failed —it always fails somewhere in the end—, containment worked, and detection allowed a reaction. All three are necessary, and the one most often neglected is the third.

We have built Rutas Norte's complete network strategy, layer by layer:

• Microsegmentation starts from denying by default in all three environments, with policies per component rather than per namespace, and with a periodic review of which conversations are still needed.
• Egress traffic control is the layer that decides whether a compromise turns into a data breach. Four of Rutas Norte's six components do not need to reach the internet at all, and closing their egress is the highest-value, lowest-cost measure in the whole lesson.
• NetworkPolicies work with IPs, not domain names. The ways out are the egress gateway, the proxy with an allow list of domains (which also logs the destinations) or Cilium's toFQDNs policies.
• Inside the cluster, past the Ingress TLS, everything travels in the clear. The options are TLS in the application (a priority for bookings-postgres), CNI-level encryption with WireGuard (cheap and effective between nodes) or mTLS with a service mesh.
• A service mesh gives cryptographic per-workload identity, automatic mTLS and L7 authorization, in exchange for operational complexity, resources and latency. Rutas Norte does not need one today, and we have set objective criteria for revisiting that decision. Istio (sidecar or ambient), Linkerd and Cilium Service Mesh cover different profiles.
• At the perimeter: a single entry point (no NodePort), a WAF adopted gradually, rate limiting and security headers.
• The control plane deserves its own review: an apiserver that is not exposed, etcd encrypted and with the Secrets rewritten, encrypted backups, an authenticated kubelet with no read-only port, and control nodes isolated with taints.
• What NetworkPolicy lacks is logging. Hubble, or an egress proxy's log, turns internal probing and exfiltration attempts into something visible and alertable.
• Zero trust boils down to assuming compromise: not "how do I stop them getting in", but "when they get in, what can they do and how quickly do I find out".

With this, Rutas Norte's network is segmented, with controlled egress and visibility of what happens. But notice something: everything we have done in this module protects the cluster at runtime. We take for granted that the images we run are the ones we think they are.

And that assumption is fragile. registry.rutasnorte.example/bookings-api:2.7.1 is a tag, and a tag can be reassigned: the image pulled yesterday may not be today's. The base image it was built on may contain software nobody has reviewed. The dependencies installed during the build come from public repositories. And nothing, absolutely nothing, stops somebody with registry access today from pushing a modified image under the same name and having the cluster run it without complaint, with all our securityContext settings perfectly applied to a container that does something different from what we think.

The next lesson, 08-05, Image Security, walks the whole supply chain: where an image can be poisoned, how to build minimal images, why the digest is the only genuinely reproducible reference, how to sign with Cosign and —most importantly— how to make the cluster reject any unsigned image, with the admission policy that guarantees it.