“Zero trust” is a security philosophy that assumes that all network resources are potentially untrusted and requires strict verification for access. It is different from traditional security models, such as VPNs, where a user only needs to log in once to gain access to multiple resources. With zero trust, a user must authenticate (or log in) each time they want to access a specific resource, which provides a higher level of security.

To better illustrate, let us first look at a high-level representation of the security model using the more traditional VPN approach.

Here, a user needs to access protected resources such as APIs or databases, but the user is outside of the company network. In modern computing, this network will often be referred to as a VPC, or Virtual Private Cloud. So a server is installed inside the VPC to allow the user to tunnel into the network, and thereby access the protected resources that they need to access to do their job. This is often referred to as a VPN server, or sometimes a bastion host.

Problem Statement

What I just described is a very common approach across the industry, but it has two significant drawbacks – problems which most companies have just learned to accept over the years:

• VPNs are overly permissive, and thereby pose an inherent security risk
• All web traffic gets funneled through a VPN, thereby creating bottlenecks and slow connections for the people using it

Because a VPN connection grants total access to every resource within the VPC, this means the risk is always present that a would-be-attacker gains the keys to the kingdom once they manage to get into the network. This is sometimes called the “castle and moat” model. The moat does an okay job keeping out intruders, but it’s easy to imagine that different attack vectors (opportunities for people to jump over that moat) will open up the more the network matures.

And VPNs are just not well-suited to support a high number of concurrent users, which often means increased latency and thus poor user experience. Each employee connecting to the VPN consumes some of its finite bandwidth, as all of their web traffic (whether that traffic is work-related or not!) is transmitted, thereby exacerbating the problem.

Enter Zero Trust

I’m delighted to tell you that there’s a better way. With zero trust networking, you end up installing something called an Identity-aware Proxy, or IAP. This is different from a VPN server because it runs software that is designed to proxy network traffic in a granular way.

An IAP is configured so that users must authenticate against each and every resource separately – whether that is a website, database connection, SSH access, and so on. (And don’t worry, session cookies ensure that the user isn’t encumbered by multiple logins in a row). But each resource in the VPC can have its own, separate security policy. So although traffic does still funnel through a single IAP, it’s different from a VPN server because it only proxies traffic to the single resource requested. This also means that each resource gets its own security policies, so for instance, a system administrator could open up access to api01.amfamlabs.com to John Smith but not api02.amfamlabs.com, even when both systems are deployed in the same VPC.

This also means that a Zero Trust approach to networking solves the latency problem, because only specific resources are proxied through the IAP rather than all web traffic.

Our Experience

In December 2020, DSAL began migrating all our micro services to a zero-trust networking model. We did so by utilizing an open-source IAP tool called Pomerium. At the time we began this journey, this particular tool seemed like the most mature and easy to adapt to our existing network model. But since that time, there has been a proliferation of other offerings, including Hashicorp Boundary, Google IAP, and even Ngrok. Although zero trust networking may still seem like an emerging technology to some, we have seen widespread acceptance and implementation of IAPs across different enterprises and sectors, especially as larger providers like Microsoft and Cloudflare continue to advocate for its adoption.

We have a centralized deployment of Pomerium which connects into Amfam’s identity provider (IDP), and then we deploy any number of Pomerium proxies across our various Kubernetes clusters, in a hub-and-spoke model. This allows us to write routes and policies for our services without needing to wait on external teams, while still ensuring that access control is kept within the enterprise, by the nature of utilizing the shared IDP. In short, we get flexibility and security rolled up together.

Growing Pains

However, we have still kept many of our previous VPN servers active. The reason is simple: it is much harder to deploy and configure an IAP for each and every service, than it is to set up a single VPN server. And this is precisely why many companies continue to utilize VPNs as their primary security posture, because VPNs are cheaper and easier to set up. This can be likened to switching our power grid away from fossil fuels and over to renewable energy sources. Everyone knows that it’s a good idea, but it is hard to execute on and sometimes expensive. And we have to accept the fact that we will continue to burn some amount of coal along the way.

In our analogy, VPN servers are like coal power plants, whereas IAP deployments are like solar. The end goal that any modern technology company which cares about security should be the elimination of VPN networks as a paradigm altogether. But because there is a non-zero investment in setting up an IAP and then configuring routes and policies for every new service, it is a practical necessity that VPN servers will still be needed, at least until we pass a certain threshold where critical systems and services are connected in through the IAP.

We have been able to cut down on the need for the VPN connection dramatically at DSAL. When I first started here years ago it was common practice to begin my day by starting up the VPN connection. Nowadays, I only connect to the VPN when absolutely necessary. So we are already well on the path, thanks to our talented DevOps engineers and their prolific use of Pomerium. But we still have a little ways to go.

Conclusion

After three years of experimentation and refinement, DSAL has matured our zero trust model in network design, infrastructure, as well as the team’s collective skill set. We have even developed some shared tooling and libraries that can be utilized across the enterprise, particularly relating to programmatic access to web-based resources.

Do you have questions about the renewable, zero trust future ahead of us? Would you like to learn more about implementing IAPs in your environment? Get in touch with us. We’re happy to share what we’ve learned. Or to learn even more about zero trust networks, check out Pomerium’s blog post titled, “Demystifying Zero Trust.”