Our Recommendation
We can only recommend HashiCorp Boundary to organizations that are already fully invested in the HashiCorp ecosystem and do not care for a full zero trust architecture.
Boundary’s native integrations with HashiCorp Vault and Terraform are useful for resource discovery and credential management, but Boundary is lacking when it comes to critical security features like continuous verification and context-aware access.
For security conscious organizations looking to reduce their attack vectors, we still recommend Pomerium. Our reverse proxy enables zero trust access control where trust flows from identity, context, and device, continuously checked on each action and request.
Evaluators Should Know
We base our comparison on a strict four-pillar criteria when evaluating access control solutions:
Usability: Boundary provides some value here when it comes to resource discovery and providing users a dynamic resource catalog. Unfortunately, Boundary also uses client-based access for users to login and establish user sessions, which does not score well on our usability criterion.
Speed: Boundary can be deployed at edge in VMs and containers close to the target resource. When architected correctly, Boundary should be comparable to Pomerium in speed and latency. This may not be true when using Boundary’s multi-hopping feature.
Security: Boundary brings identity-aware access and integrated credential management via Vault, but only does authorization and authentication checks on session start. It does not have continuous verification. As a result, Boundary is unable to mitigate the problems of compromised credentials or malicious insiders.
Context-Aware: Boundary can only accomplish IDP-level context. It cannot leverage external data sources into its access control decision-making process the same way Pomerium does.
Additionally, here are some additional considerations specific to Boundary that any decisionmaker would want to know.
High cost of ownership
Your DevOps and SRE teams will be wrangling with Boundary’s three main components:
Control plane - (Authentication happens here) - This is where Boundary’s resources and permissions are, and are made up of Controllers. Users use their client to authenticate to controllers, which in turn communicate with external components such as the database, KMS, Vault, identity providers, and plugins.
Data plane - (Connection brokering happens here) - This is the network proxy, made up of Workers. Instead of exposing a private network to the public, or allowing users to have access to entire private networks, workers create a direct network tunnel between users and targets.
Client - (Logging in happens here) - These are the clients expected for any client-based access, installed on the user's device.
Example reference architecture pulled from Boundary:
And here’s a standard access flow with Boundary:
User logs in to Client.
Client passes on credentials to Controller. Controller authenticates with IdP, checks authorization and permissions of the user.
After Controller verifies User, User selects from a host catalog for the resource they want to access.
Controller pings a Worker in charge of the Resource. Worker receives the session request, then opens up a tunnel from resource straight to User Client.
User has started a session with access to resource.
Tunneling solutions are not zero trust
Zero trust grants access based on continuously verified identity, device, and context
As a tunneling solution, Boundary only checks on session-start with limited context-awareness
HashiCorp Boundary is very much a tunneling solution under the hood. They made specific architecture decisions to avoid the Perimeter Problem. Unfortunately, their design choices actively result in the aforementioned higher cost of ownership as well as reduced security because tunnels cannot enforce continuous verification.
We can understand how they arrived at this architecture. The traditional VPN setup involves creating network perimeters around sensitive corporate networks, then providing users a tunnel past the perimeter defenses. Once inside, the user has access to the network — and this caused lateral movement. No doubt HashiCorp saw this and asked themselves the same question Twingate was trying to solve: “What if we could only give users a tunnel straight to a target resource itself, thus reducing the possibility of lateral movement?” As a result, they designed their Controllers and Workers architecture to ensure that users only get access to the target resource and not the network itself.
While this largely solves the lateral movement issue, there’s a reason why it isn’t zero trust: tunnel solutions can’t enforce continuous verification on each action. Boundary’s architecture makes the organization susceptible to compromised credentials and malicious insiders.
This is because Boundary only enforces authentication and authorization checks before connecting a tunnel from resource to client and establishing a user session. Once a user session has begun, Boundary no longer inspects that user’s actions. This presupposes that:
the credentials supplied for logging in were used by the intended user, not stolen
the user has not been compromised or turned malicious, and their actions are fully sanctioned
Compromised credentials happen to be one of the most common vectors of attack and malicious or negligent insiders are prevalent. Boundary’s ability to provide a dynamic resource catalog is a double-edged sword; if a hacker gains access to an account with high privileges, the hacker is served with a catalog of all resources Boundary has access to instead of needing to do a search for these resources themselves. You’ve limited lateral movement on a technical basis, but made it significantly easier for a hacker to gain realistic access.
Session recording sounds great but is impractical
Recorded sessions are great in theory and terrible to sift through in practice.
We meant it literally when we said "camcorder on" for session recording. Boundary can record a session’s screen for internal auditing by admins, and here’s HashiCorp’s own demo of SSH session recording.
Now imagine scaling that for multiple servers over hundreds of users as administrators hunt down a problem.
Session recording is useful in limited situations — specifically, you should know:
Otherwise, auditing session recordings are an expensive time-sink of watching recordings in the hope of finding what you may or may not be looking for. It does not scale efficiently and is a poor of use admin time. Boundary attempts to address this with audit events, but is not on a per-request basis.
Pomerium’s audit logs fix this problem by logging the details of every request including why an action was approved or denied, resulting in faster time to identify or fix security protocols. Save your admins time watching session recordings by giving them searchable audit logs.
Try Pomerium
HashiCorp Boundary falls short compared to what we want in an access control solution.
Pomerium’s place as an open-source context-aware reverse proxy helps prevent ransomware attacks on internal services and resources. Whether you’re spinning up a new application or trying to add access control to a legacy service, Pomerium builds secure, clientless connections to internal web apps and services without requiring a corporate VPN. The result is:
Easier with clientless access.
Faster by being tunnel-free and deployed where your apps and services are.
Safer because every single action is verified before allowed to execute.
Tailored to your organization’s needs by integrating all data for context-aware access.
Give Pomerium a try today!
