Improving your Zero-Trust Security with Cloudflare Access and HashiCorp Boundary

Introduction

When building or moving to a cloud-based environment, it is critical to evolve your security tools and methodologies along with it. In the past, security could largely be managed based on the knowledge that you have static endpoints and a clearly defined network perimeter; allowing for a clear line of trust in determining access controls. The continued adoption of cloud infrastructure and applications has rapidly replaced this old network structure with one filled instead with dynamic endpoints and less clearly defined perimeters to private networks.

This new paradigm has given rise to the concept of the “Zero-Trust Security Model”, a concept which provides no inherent trust or network access to any user, device, or IP address. This model assumes that there is no defined network edge and is instead focused on strict identity-based access for each user. A user must have both the authentication and authorization to access a network asset and be continuously re-validated to ensure that their permissions have not changed and that their identity has not been compromised. This model also focuses on the principle of least-privilege and limiting network visibility to only what is needed, minimizing the attack surface of potential threats.

At Ascolta we continuously strive to find and implement new tools that help us improve upon our implementation of this Zero-Trust Security Model. Methods such as Single Sign-On, Mobile Device Management, and Multi-Factor Authentication form a solid foundation for this, but there is always room for more secure and fine-grained control to network access. Two of these tools that we have been excited to make use of are Cloudflare Access and HashiCorp’s Boundary.

In this article, we will show how you can take a standard VPN-protected private network and implement these two tools to amplify your zero-trust practices. We’ll start by handling external threats with Cloudflare Access, where we will remove our VPN edge device; eliminating standard internet ingress to our network while still allowing authorized users in. Next, we’ll protect our internal network resources by using Hashicorp’s Boundary to restrict network visibility, better contain threats, and add strict identify-based access to individual resources.

Eliminating External Threats with Cloudflare Access

A common approach to securing a cloud environment is to create a Virtual Private Network (VPN) to act as the perimeter. Below is a simplified diagram of a network using a typical VPN implementation. For now, we are only focused on our network perimeter, and will discuss internal network concerns later:

In this model, the client would download and install a VPN client onto their machine. The user would then login to their company's network using this client; ideally via an identify provider connected to the VPN. Once connected, the user then has access to endpoints within the network.

The edge device used to run the VPN also functions as the primary line of defense against unauthorized users. This is a very simple example but illustrates a common problem – the VPN’s exposure to the internet.

The problem: We are exposed to the internet

Regardless of how well-managed and protected an edge device is, it is inevitably still accessible from the wider internet, and as such open to multiple attack vectors from malicious sources. Servers such as the one used for the VPN are extremely valuable targets and are rapidly becoming a major focus of online threats. Traditional methods for protecting edge devices are struggling to keep up with this, and failure to do so can compromise your entire network. This is where Cloudflare Access comes in; with it, we can remove our edge devices from the internet entirely while still allowing legitimate users to access the network securely.

The solution: Remove the edge device entirely with Cloudflare Access

Cloudflare operates one of the world’s largest networks, and their services provide a backbone to a significant portion of the modern internet. They are a trusted American company with a strong focus on security and performance, and their Cloudflare Access service allows us to reinvent the way we think about our network perimeter. (Cloudflare is also in-process on the FedRAMP Marketplace) Cloudflare Access completely replaces the need for a traditional VPN; it hooks in to modern identify providers to give us strong, identity-based access to our network. Most importantly it requires no ingress rules into our network, essentially removing our network edge entirely. Doing this protects us from a vast number of online threats affecting traditional VPNs and similar devices.

Let’s see how our network perimeter looks once we’ve implemented Cloudflare Access:

This adds several new components, so let’s breakdown each of them. We'll begin inside of the network and work back to the user:

• The Cloudflare Access Tunnel Server: This lightweight server runs a service that talks out to Cloudflare’s edge network. This service can be run on a single server to act as a sort of proxy to the rest of the network (which we have done here), or on individual servers within our network for more partitioned access control. Note that this exclusively communicates in an egress-only fashion from the network, with zero ingress rules into it.

• Cloudflare Access: External to our network is Cloudflare’s edge, which is what our internal Tunnel Server reaches out to. The Access service here functions as the gatekeeper to our network; admins can establish who or what is able to see/connect to our private network though Cloudflare’s interface.

• Identity Provider: Cloudflare Access integrates cleanly with an identity provider such as Azure AD, Okta, Google, etc. This provides us with strong identify-based access to our network.

• Cloudflare WARP: Cloudflare WARP, part of their larger Zero Trust service, is a client that users run on their local systems to send traffic privately and securely through Cloudflare’s edge. In this setup it is required to access our network.

From the user’s perspective, this largely functions the same as a VPN client. Access to the network would follow this workflow for them:

1. Download the Cloudflare WARP client to your local machine

2. Within WARP, login to the identify provider via Cloudflare’s Zero Trust service

3. Assuming you have successfully authenticated and are authorized to do so, you are now on the private network and can connect to internal endpoints

The core benefit of this is a simple but crucial one – our network and the resources inside of it are no longer exposed to the internet. Cloudflare Access requires no ingress firewall rules whatsoever; the service only needs to communicate via egress in order to function. All user communication to it and the private network beyond it happens at this service layer, rather than through the network perimeter itself. Unauthorized users can never see or touch our actual network perimeter, as they are blocked by Cloudflare’s highly secure and managed network as well as our identity provider.

This also reduces administrative overhead; rather than managing/protecting our own edge device we can rely on Cloudflare’s edge to stand in front of our own. We can also make use of any additional security tooling we have configured with our identify provider and centralize access logs and monitoring to it. As an added benefit, the WARP client lets us apply strict security policies and DNS/HTTP filtering to user traffic.

There is a large array of additional tools and options Cloudflare can provide once we are integrated with them, but for now we have created a substantially more secure entryway into our network and removed our own edge entirely.

Managing Internal Connections with HashiCorp Boundary

Now that our perimeter is secure, let’s expand our network example to include some internal endpoints that a user may need to access:

Once connected to the network, in this case via Cloudflare, the user is essentially “inside” of the network. Further access to specific endpoints is managed by internal firewall and credential systems. In this case the user has static credentials to a development server and database. They do not have credentials to the admin server but are still able to see it and attempt to connect.

Our Cloudflare deployment has helped to significantly lock down access to our network and eliminate many external threats, but what about internal threats? Per Zero-Trust best practices, we must assume that even legitimate users or systems on the network have the potential to become compromised. Since any user could introduce malware, unauthorized access, or other threats to our endpoints, we need to limit what they can see/access as much as possible.

The problem: Excessive network visibility, poor threat containment, and static credential management

Once authenticated through Cloudflare the user has visibility to the entire network, greatly increasing the attack surface of a compromised client. Just because a user isn’t supposed to have access to an admin server doesn’t prevent them from attacking that endpoint in various ways. Even being able to obtain metadata on inaccessible endpoints can result in a security threat.

Malware or stolen credentials on a client are poorly contained and can quickly compromise multiple endpoints. Connections are not well isolated and essentially always open; the entire network must now be considered when investigating any security threat.

Another issue is that authorization and authentication methods are less centrally managed and may depend heavily on static user credentials or complicated firewall rules. The way a user authenticates into the network is entirely different from how they authenticate to individual endpoints. This adds more administrative complexity and potential for error in access controls.

The solution: Restrict network visibility and centralize access management with HashiCorp Boundary

Boundary by HashiCorp is a lightweight deployment (with support for High Availability) that can sit anywhere within your network, ideally behind an initial access point like Cloudflare’s Access Tunnel. With Boundary, administrators can configure “targets” pointing to any endpoint system or service within the network. They can then define exactly what targets users can see and access with precise control and multiple configuration options. Users can then connect to Boundary and establish short-lived connections to individual endpoints via a local proxy.

Boundary also ties into identity providers like Azure AD and credential brokers like HashiCorp’s Vault to further maintain our Zero-Trust Security Model. This all provides us with a powerful new layer of control and access protection in environments that are becoming ever more complex and dynamic.

Let’s see what our network looks like once we add Boundary:

Once again, we’ve added several new components, so let’s step through them:

• Boundary Controller: This is the primary server used by admins to manage user access to network endpoints; these “Targets” can be anything from static IPs, to DNS, to service meshes like Consul. This server is also used by clients to list and establish connections to their authorized endpoints.

• Boundary Worker: The worker is responsible for handling the actual connections to the targets. After receiving valid authorization and authentication from the Controller, the Worker creates a temporary proxy through which the user can connect to their endpoint.

• Database: The backend of Boundary is a Postgres database; in this case an Amazon RDS instance. The database manages all target and user configurations and tracks their active sessions.

• Identity Provider: Boundary hooks into an Identity Provider like Azure AD to provide strong identify-based access. AD groups can also be linked to Boundary target groups to more easily organize user access.

  • Note - This is the second time we connect to the Identity Provider in this solution, with the first happening externally in Cloudflare. This additional layer of authentication both strengthens our Zero-Trust Model and gives us flexibility on when/where to require reauthorization.

• Vault: This is another HashiCorp tool (either self-hosted or managed by HashiCorp) that can provide just-in-time credentials to the endpoint a user is accessing. Vault is a powerful tool that we can review more in-depth in a later article.

The workflow for accessing an endpoint in the network now looks like this:

1. The user authenticates via the Cloudflare WARP client to access the network, and then logs into the Boundary Controller via an identity provider such as Azure AD. Boundary provides both UI and API options for connecting to it.

2. Boundary queries its database for what targets this user has access to (as defined by admins) and presents them with a list of only those endpoints.

3. The user selects a target, and the Boundary Controller sends a signal to the Boundary Worker to authorize that session for the user. It can also establish temporary access credentials to the endpoint using HashiCorp Vault.

4. On the user’s system, a proxy through their local host is created to the Boundary Worker, which then further proxies that traffic to the desired endpoint. The user is also provided with any temporary credentials created by Vault, such as a one-time password.

5. Finally, the user can now access the endpoint by connecting through the local port that Boundary has provided for the session. Each session uses a different port and connection, keeping their traffic isolated from each other. Sessions automatically expire after a time limit set by administrators.

While this may seem complex at first, it results in a very simple workflow for the user, and much more centralized and manageable access controls for administrators. Let’s go over some of the benefits we have in this Boundary-focused network compared to our non-Boundary network.

Crucially, Boundary only allows users to see and connect to endpoints that they are authorized for; all other endpoints are essentially non-existent to them. In our example things like the admin server are completely invisible to someone who has no access to it. This results in a significantly smaller surface area for attack from a compromised client.

Notice the individual sessions in the diagram: Each connection is isolated from the other and only lasts for the session’s configured time limit. Malicious code or stolen credentials on a client are now much easier to contain due to the nature of these sessions. If a threat is discovered you only need to be concerned about the systems that the user had access to and what sessions were open at the time, rather than the entire network.

Authorization and authentication are more centralized now with Boundary. Admins can easily manage who is able to see what (based on either internal Boundary groups or from AD groups) and make full use of the identity provider’s security tools. Additionally, temporary credentials from Vault can remove the need for static keys or disparate credential systems that can be difficult to manage or end up stolen.

Once deployed, Boundary can make the day-to-day workflow for both users and administrators easier and more secure. While already in a fully functional and useful state, HashiCorp is rapidly developing this product and it is likely to see numerous improvements and enhancements in the near future. 

Ascolta Can Help with Enterprise Zero-Trust Solutions

With Boundary and Cloudflare in place, we have greatly improved our Zero-Trust Security Model both inside and outside of our network environment. External entry is heavily regulated and protected by Cloudflare’s services, with no traditional edge device or direct ingress into our network. Meanwhile internal connections and network visibility are strictly controlled and isolated using HashiCorp Boundary.

At Ascolta we have found ample success in implementing these tools and now use them daily. With these tools you can form a modern zero-trust foundation as you build up a robust, manageable, and (most importantly) secure cloud-based environment for your organization. We’re happy to consult and work with you on your path to zero-trust, drop us a line here to get started!

References

You can learn more about Cloudflare Access and their greater Zero Trust services at the links here:

Cloudflare Access: https://www.cloudflare.com/products/zero-trust/access/
Cloudflare Zero Trust: https://www.cloudflare.com/products/zero-trust/

If you are interested in Boundary, you can follow HashiCorp’s tutorials and watch their own introduction video here:

Boundary Tutorials: https://learn.hashicorp.com/boundary
Introduction to Boundary: https://www.youtube.com/watch?v=tUMe7EsXYBQ

HashiCorp also provides several other tools that can help you both deploy these systems and further develop your environment. This includes Terraform providers that can be used to manage both Boundary and Cloudflare services, as well as Vault, which can work as a just-in-time credential broker as seen above:

Boundary Terraform Provider: https://registry.terraform.io/providers/hashicorp/boundary/latest/docs
Cloudflare Terraform Provider: https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs
HashiCorp Vault: https://learn.hashicorp.com/collections/vault/getting-started

If you’d like to read more about Zero-Trust Security in general, here are some articles to get you started:

HashiCorp’s introduction to Zero Trust: https://www.hashicorp.com/solutions/zero-trust-security
Microsoft’s white paper on the topic: https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RWJJdT