Day Two Cloud 094: Exploring ZTNA

Once a term becomes sufficiently ubiquitous, marketing teams need to invent a new term that describes exactly the same thing the old term did. It’s New! and Improved!. Now with 100% more Interrobits per Kilojoule! The latest buzzword in the world of networking and security is Zero Trust Network Access or ZTNA. In this episode, Ethan introduces me to the world of ZTNA with a bit of theory on what the term means, and some concrete examples of how different vendors are implementing it.

Of course the term Zero Trust is a bit of a misnomer. There is a LOT of trust in these networks. But trust is not assumed from the get go, rather clients on the network need to establish trust with each other through a mechanism like certificates or pre-shared keys. A ZTNA solution also applies policies to the network governing communication between clients, making a simple establishment of trust not enough to open a channel of communication. Not only does one client need to trust the other, it needs to trust the contents and context of the request.

The solution that prompted some additional reflection from me was Araali networks. Their solution is using eBPF, so it’s Linux only. Since it works at the kernel level, that means it doesn’t have to implement some esoteric network protocol to perform inspection of packet flows. When you’re in a situation where you need to deploy a ZTNA solution to cloud environments, adding a middle box or using a tunneling protocol might not be an option. But as long as you have Linux machines, you can implement this solution. And it snaps right into Kubernetes as well.

Reading through their docs, there are a couple key threads to pull on.

First, they use identity based authentication between services. Rather than trust communication based on a five-tuple of source, destination, ports, and policy; instead you are focused on the identity of a service and how it should communicate with other services on the same box or a remote system. The identity is established using SPIRE, which is a whole other show I suspect, giving each application an authentication ID which it can use to establish trust with another application. I like this a lot more than relying on IP addresses and ports, since that assumes a relatively static environment, something that K8s and cloud are decidedly not.

Second, they are designing policy based on observed behavior. It looks like the system runs in a monitor mode to build a profile of what network traffic is considered normal, and then it develops policies to enforce that profile. Once you review what is in those policies, you can switch the system to enforcement mode and start blocking requests. My question would be how it handles the introduction of new applications? Does the team adding the new application need to also develop a policy document for Araali to make sure their initial traffic requests aren’t blocked? Assuming this is a whitelist type environment – which any zero trust network would be – any new service would be blocked by default. One potential approach I derived from their website is running Araali in monitor mode on your Dev environments to build an application profile, and then copying that profile over to Prod when the app is launched there. That makes a lot of sense and even fits into a CI/CD pipeline mentality.

I think there’s a lot more here to dig into, and I am going to plan out some Day Two Cloud episodes that go deeper on SPIRE and eBPF. If the future of cloud networking is ZTNA, then I think we need to understand those core technologies.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.