For a long time, network security worked like an office building with a security desk at the entrance. Once you were through the door, you could walk into most rooms. Firewalls guarded the perimeter, and anything with an address inside it was treated as a colleague.
That model assumed the perimeter meant something. It no longer does. Staff work from home and from depots on LTE connections. Partners connect to APIs. Workloads run across cloud regions and data centres. And the most common way attackers get in is not by breaking through the firewall but by using stolen credentials, which give them an address inside it. Once there, a flat internal network lets them move from one compromised system to the next.
Zero trust is the response. It does not mean "trust nothing" in some absolute sense. It means that network location is not enough to establish trust. Every request is verified explicitly, based on identity, device, workload, policy and context. Network location remains a useful signal and a useful control. It just stops being the deciding one.
Network location is weak identity
An IP address tells you where a packet appears to come from. It does not tell you who sent it, whether their device is healthy, or whether the process that sent it is the one you expected. In a cloud estate it may not even tell you which workload sent it, because addresses are reassigned constantly as containers and instances come and go.
That is why the US National Institute of Standards and Technology frames zero trust around resources and identities rather than network segments. Its architecture reference, NIST SP 800-207 (2020), sets out the principles; the follow-up practice guide, NIST SP 1800-35 (final in June 2025), shows example implementations built with commercial products. Both are worth reading if you are designing at enterprise scale. For a shorter practical introduction, our earlier piece on zero trust in practice covers the organisational side.
Segmentation and microsegmentation
The two terms describe the same idea at different sizes.
Segmentation separates larger trust or routing zones: production from non-production, regulated workloads from ordinary ones, the depot network from the head-office network. Parts 4 and 9 built these boundaries for Hadeda Freight, the fictional freight company whose Track platform runs through this series. Hadeda Freight is fictional, and its address ranges and figures are illustrative.
Microsegmentation applies much finer policy, between individual workloads, instances, containers or services. Instead of "production may talk to production", it says "this service may call that service, on this port, and nothing else".
The way the policy is written matters as much as how fine it is. Compare two rules for Track:
The billing service may call the payments service on HTTPS.
Anything in
10.40.20.0/24may reach anything in10.40.30.0/24.
The first refers to stable identities. It stays correct when the billing service scales from three instances to thirty, moves to a different subnet or is redeployed with new addresses. The second refers to address ranges. It allows every workload that happens to land in the application subnet, including ones that did not exist when the rule was written, to reach every workload in the data subnet.
IP-based controls do not disappear. They remain necessary in many systems, and they are a useful outer layer. But in an environment where addresses change by the minute, the policy that does the real work should follow the workload rather than its current address.
North-south and east-west
Two terms are worth knowing because they describe where traffic, and risk, actually flows.
- North-south traffic crosses the boundary between the workload environment and the outside: users, the internet, a data centre or a partner. For Track, that is customers and drivers reaching the API, and Track calling its payment provider.
- East-west traffic moves between services inside the environment: shipments calling notifications, billing calling payments.
Most organisations already inspect north-south traffic carefully, at the edge. East-west traffic is where the gap usually is. As an application is split into more services, east-west traffic grows faster than north-south. And if every internal service can call every other one, a single compromised service becomes a launching point for the rest.
Four controls, used together, close that gap:
- Service identity: each workload gets a cryptographic identity, rather than being known by its address.
- Mutual TLS (mTLS): both sides of a connection present certificates, so each knows exactly who it is talking to, and the traffic is encrypted.
- Network policy: only declared service-to-service flows are permitted.
- API authorisation and controlled egress: even an allowed caller may only perform the actions it is entitled to, and a compromised service cannot freely reach the internet.
Where each control belongs
A common mistake is to expect one layer to do everything. A clearer approach for Track:
| Layer | Question it answers | Example at Hadeda |
|---|---|---|
| Network segmentation | Which zones may exchange traffic at all? | Non-production cannot reach production |
| Workload identity and mTLS | Is this caller really the billing service? | Payments accepts only the billing identity |
| Network policy | Which service pairs may connect, on which port? | Billing to payments on 443, nothing to admin |
| API gateway and authorisation | May this caller perform this action? | Billing may create a charge but not issue refunds |
| Application logic | May this user see this record? | A customer sees only their own shipments |
Each layer catches mistakes in the layer above. A network policy accidentally widened during an incident is still backed by mTLS and API authorisation. A stolen API token still cannot reach the payments service from a workload that has no network path to it.
Containers and Kubernetes
Kubernetes, the most widely used container platform, adds several networking layers of its own, and each has a security consequence:
- Nodes are the machines that host workloads.
- Pods are groups of containers, each with its own address, often from an overlay network the cloud network does not see directly.
- Services give a stable name and address in front of a changing set of pods.
- Ingress or Gateway resources bring external traffic into the cluster.
- Network policies control which pods may talk to which.
- DNS-based service discovery lets pods find services by name.
- Sometimes a service mesh adds identity, mTLS and traffic policy between services.
Two details catch teams out. First, by default, pods in a Kubernetes cluster can generally reach each other freely. Network policies are how you turn that into a declared set of flows, and they only take effect if the cluster's network plugin enforces them. Second, at the time of writing (October 2026), the Kubernetes project recommends the newer Gateway API for routing traffic into a cluster. The older Ingress API is frozen (still supported, but no longer developed), and the widely used ingress-nginx controller reached the end of its maintenance in March 2026, which means no further releases or security fixes. Any cluster still relying on it has a migration to plan.
A service mesh is not automatically required. It adds proxies or node-level components, certificates to rotate, telemetry to store, policy to manage and a new thing to upgrade. It earns its place when the service-to-service requirements, such as mTLS everywhere, fine-grained traffic policy or detailed per-call telemetry, justify that cost. Hadeda, with three product teams and a modest number of services, started with network policies and API authorisation, and has written down the triggers that would make a mesh worthwhile.
DNS at enterprise scale
DNS appears in almost every part of this series because it sits in front of almost every connection. At enterprise scale it becomes a production system in its own right, and the design has to answer some specific questions:
- Which team owns the public domain and its delegation?
- Which private zones exist in each cloud and environment?
- How do office and cloud resolvers forward queries to each other?
- How are private endpoint records created, and who removes them when the endpoint goes away?
- How is DNS protected against unauthorised changes, and against DNS tunnelling (using DNS queries to smuggle data out)?
- What happens to name resolution when the hybrid link fails?
That last question is the one most often left unanswered, and Hadeda learnt it the hard way. When the Durban depot's fibre went down one weekend, the LTE backup came up but had no route to the API's private address, so scanning stopped. Fixing the route was only half the answer. The review found a second, latent gap: the depot's resolver forwarded queries for api.hadeda.example to the cloud resolver endpoint over that same failed path, and had only kept answering from its cache. A longer outage would have broken name resolution too. Hadeda now gives the backup path both a route and a way to resolve names, and documents what the depot should do when both links are down.
Treat DNS like any other production dependency: give it redundancy, monitoring, change control and a recovery procedure.
Common mistakes
- Treating "inside the network" as trusted. One stolen credential then reaches everything.
- Writing policy against address ranges in a container platform. Addresses change constantly, so rules drift from what they were meant to allow.
- Assuming Kubernetes network policies are enforced. Without a network plugin that enforces them, they are just documentation.
- Adopting a service mesh because it is fashionable. You inherit its operating burden without the requirement that would justify it.
- Leaving DNS ownership implicit. Stale records and unplanned link-failure behaviour cause outages that look like application bugs.
Try it yourself
Take five Track services: shipments, billing, payments, notifications and customer admin. Write down the minimum set of allowed service-to-service relationships, each with a direction, protocol and reason. Then, for each relationship, decide which controls belong at the network layer, the workload identity layer, the API layer and the application authorisation layer. Finally, list what happens to each service if the identity provider is unavailable for ten minutes.
Test your understanding
Why is "billing may call payments on HTTPS" a stronger rule than one based on subnets?
Answer: It names the identities that matter and stays correct as instances scale or move. A subnet rule allows anything that happens to land in that range.
What is east-west traffic, and why does it grow faster than north-south?
Answer: Traffic between services inside the environment. Splitting an application into more services adds internal calls far faster than it adds external ones.
A Kubernetes cluster has network policies defined, but pods can still reach each other freely. What is the likely cause?
Answer: The cluster's network plugin does not enforce network policies, so the policies have no effect.
Does zero trust mean the network no longer matters?
Answer: No. Network location stays a useful signal and control. It simply stops being enough, on its own, to grant trust.
What to take from this part
Location is a signal, not a credential. Verify identity, device and context for every request.
Write policy against identities. Address-based rules drift as soon as workloads scale or move.
Close the east-west gap. Service identity, mTLS, network policy and API authorisation together stop lateral movement.
Choose a service mesh on evidence. It is a capability with a running cost, not a default.
Run DNS as a production system. Ownership, redundancy and link-failure behaviour need to be designed, not assumed.
Next in the series: Network resilience, observability and cost: designing for the bad day.
How CloudNala can help
We help teams move from perimeter-based trust to explicit service policy without boiling the ocean: mapping the real service-to-service flows, deciding which controls belong at which layer, planning the move from Ingress to Gateway API, and making an honest call on whether a service mesh is worth its operating cost.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Request a Cloud Network Review or write to us at consult@cloudnala.co.za