HashiCorp Boundary: Software Defined Perimeter for the Modern Network
HashiCorp Boundary: Software Defined Perimeter for the Modern Network
Earlier this week I was excited to be invited to an early preview of HashiCorp’s first new product in a few years, HashiCorp Boundary. The…
Earlier this week I was excited to be invited to an early preview of HashiCorp’s first new product in a few years, HashiCorp Boundary. The NDA on releasing this information has now been released, and I want to talk about nothing else. Let’s talk Boundary!
Boundary is the first new product from HashiCorp in the past several years and was announced at HashiConf2020. It is intended to modernize how network access is provided to both users and applications.
Boundary is intended to be one of the first in the Software-Defined Perimeter space. This type of tool is an organic outgrowth of the HashiCorp consul product’s service mesh and overlay networking but expands that mesh to include other types of machines, including user machines.
What Exactly is Boundary?
Boundary is a proxy host, but there’s more nuance than that. Boundary endeavors to be the middle-man between any two networks — home computer to enterprise network, DMZ to internal, internal to internet. Because proxies have access to the network traffic that flows through them, they can do all sorts of neat tricks.
Right now Boundary only supports TCP proxying, which prevents it from decoding and injecting credentials at higher level protocols, like http, SSH, RDP, etc., but that’s coming!
One such trick Boundary endeavors to solve is authentication. Once Boundary is built out in future version to understand higher-level protocols (at launch it only support TCP), it’ll be able to inject authentication into the connections on a dynamic basis.
The implications of this are far-reaching. Imagine your users are assigned access via security group or any other method to an application. They don’t need to be given a username or password — all they do to connect is first connect to the Boundary server, then click on the application (which is dynamically populated ala Consul) and Boundary will proxy the connection right through to the application as well as handling transparently authentication and login.
No more risk of password loss because the passwords are never exposed to the users at all.
What are We Solving? Let’s Talk Problems
The network Boundary problem is solved, isn’t it? In the enterprise space Cisco Networks has a strong dominant market position with their AnyConnect solution, and OpenVPN and other open source products work great for colleges and scrappy start-ups.
The function of these tools is to bridge the client’s computer onto the enterprise network. On the enterprise-side, client computers are placed into VPN “profiles” which are generally lists of IPs or FQDNs and ports that the host is permitted to connect to. These lists must be constantly kept up to date, and are generally static and manually updated.
The VPN client connects directly to the application via the VPN network connection. Notably here, security is a real concern because clients have broad access to the internet network, and malware can use this VPN-granted access and client-entered or saved passwords to exploit your enterprise.
In the Boundary view of the world, this is old hat, and a problem to be solved. There are a few items called out that can be improved or fixed here.
One problem is identity. Even if the application backend synchronizes logins, like a database or active directory, each user must login individually to the application. There’s a not-insignificant cognitive load for the user to manage all the different usernames and passwords assigned to them in an enterprise to get into all the different applications they need to do their job.
This can be solved by the Boundary proxy through authentication injection. The application would need to support the auth method Boundary will forward to it, and once that’s in place users only need to auth to Boundary, and it’ll authenticate to every other server application.
These types of connections, like other HashiCorp products, will be built out and maintained by Hashi initially, but they welcome community involvement to develop other authentication methods, interactions, and protocols.
One that springs to mind right away is how each application must individually build a method to login as a guest non-privileged user. Imagine integrating your application with this tool so developers could, with one click!, login to the application with varying permissions or as different roles. And that’s just one example, I’m sure the community will come up with great future applications of this technology.
The integrations with other HashiCorp tools are limited at launch, but the team is excited and has some future features coming. As you can see from this diagram below, the Boundary team envisions integrating with many Identity providers like AWS SSO, Okta, GitHub, Microsoft, and others.
Their own Consul service can help to automatically populate the service catalog available on the Boundary user-facing web interface, as well as other tools from the major cloud providers, and notably Kubernetes.
And finally, on the left side of the diagram, you can see the protocols Boundary hopes to understand and decode in the future. TCP is a one-size-fits-all solution, but is limited in utility when injecting authentication or helping resolve TLS-driven problems that HTTPS will certainly see.
Boundary has just been released at version 0.1.0. As with any first release, the team very much hopes it works, and features are going to be light. However, with Hashi’s history of dreaming big plans and then executing on them, I wouldn’t expect it to remain with a skeleton feature set for very long.
A notably light feature at release which will become critical later is the ability to manage and monitor sessions across many applications via the Boundary application. An administrator can view all sessions, tokens, and potentially monitor through TLS all connections through this tool.
Tl;dr: Your InfoSec team is going to love this tool.
Boundary can be deployed as a single worker host or as a redundant cluster on top of native ec2, auto-scale clusters. At launch there is also a Docker image for both control plane and workers. There isn’t yet a Helm Chart, but the team assures me it’ll be coming very quickly here.
Challenges to Solve
One problem that all proxies have is TLS. There have been various poor solutions deployed in the past, and each is a usability or security nightmare.
Cisco’s AnyConnect solution was to use AnyConnect web interface to proxy connections to internal applications by using an iFrame in a browser. That method tends to freeze, doesn’t pass credentials forward from a browser, and is generally a huge pain to use.
Other enterprise proxies solve this problem by having the enterprise deploy a wildcard root certificate to the internal hosts, which effectively breaks the TLS model and covers up such issues as HSTS, expired certs, weak hashing or encryption, and many other issues.
The Boundary team assures me they’re working on these issues and have some solutions ready, but I’m not sure how trivial TLS will be to defeat, even with the best intentions and expertise. If nation-states fail to defeat it, then we’ll see how well Hashi will fare here.
Go Get It!
Boundary is available on HashiCorp’s GitHub public page.
You can also find information on the project here: https://www.boundaryproject.io/
Go download it and report back how it works! If you have feedback about how it works and cool things you’ve found, please comment on this story!
Good luck out there!
kyler