An objective take on how Boundary is coming along.

Boundary is much more than PAM

John Boero
HashiCorp Solutions Engineering Blog
9 min readApr 14, 2023

--

A lot of early HashiCorp products started out by solving a niche problem for the practitioner or hobbyist. They then graduated to enterprise use cases by adding collaboration and advanced cloud features. Boundary is one of our latest products and is designed for PAM in enterprise cloud from the beginning. Even with this in mind, I’ve become a really big fan of Boundary for its flexibility — not just in cloud use cases. Boundary can actually be used anywhere from cloud, edge, IoT, SMB, to even your small office or home broadband. It solves the problems of PAM and remote working in a really unique way, with what the industry is starting to call Zero Trust Network Access or ZTNA. The benefits are seriously impressive and I’ve finally replaced my own VPN with Boundary. Let me explain why I think Boundary will eventually become our number two product.

How I switched from leaky VPN to Zero Trust with Boundary.

In my consulting days, I’ve spent time at 4 of the biggest banks in the world. During one DevSecOps assessment I was handed basic credentials which I found gave me full access to a class B subnet containing a global cache of all their FX trading codebase and a wealth of other archives that nobody should have access to. Would you trust your finances with an organization like that? This is a prime example for Boundary.

What is PAM?

We are not talking about Linux PAM. HashiCorp hasn’t written a magic Pluggable Authentication Module (yet). Privileged Access Management is the concept of who has access to what resources and when. It also generally implies independent session recording and audit trails so you can’t cover up your tracks with elevated privileges. The PAM market is competitive with many vendors offering unique solutions for traditional corporate networks. Security policy by static IP addresses is a classic tenant of HashiCorp’s cloud operating model. How can you grant reliable access to a resource in the cloud if it changes IP frequently or suddenly auto-scales according to workload? Boundary aims to solve this problem and more, taking a complete zero trust approach with Identity-oriented human-to-service access.

Privileged Access Management is something Consul and Vault users might be familiar with as there is a partial feature overlap already. PAM maps a user identity to a service using a policy and provides an audit trail for accountability. Consul and Vault each cover part but not all of the PAM use case.

Consul can provide routes and end-to-end mutual TLS between services. It can also inspect and direct traffic using Layer 7 policies such as a URL or part of a request. But Consul is missing the user identity, audit trail, and protocol awareness of PAM.

Vault actually covers the user identity side. A user can authenticate to Vault via an external mechanism like LDAP or OIDC and then generate a temporary SSH certificate to access a resource. Enterprise users can even use control groups to require a number of approvals before the user has access. But Vault does not establish a route to the SSH resource or monitor whatever the user does with that credential.

Boundary combines some of the features of Vault and Consul:

  1. Authenticates user identity like Vault does via OIDC.
  2. Grants access via mTLS local socket proxy like Consul Mesh.
  3. Tracks endpoints as they change IP via dynamic host groups.
  4. Uses Boundary Workers at the edge instead of Consul Mesh Gateways.

In the future, it also will record sessions and potentially direct or limit communication like Consul does with L7 across a growing list of protocols including HTTP, RDP, SSH, Kubectl, and Postgres databases. So if this is designed for Enterprise Cloud users why should a practitioner or hobbyist care?

Why does this matter to a practitioner?

As a hobbyist, Boundary is much more than an Enterprise product. For myself, Boundary replaces a very vulnerable set of components. I’ve also found some of our partners are excited to apply this in their own home labs. Take a simple use case for example. I’m active in the Fedora community and I sometimes invite developers to remote into my lab to access exotic development hardware like ARM servers and RISC-V development boards. I also run some local services including Cockpit and a GitLab instance behind the firewall. Any traditional remote access solution usually relies on the following three components:

  1. Public DNS or Dynamic DNS.
  2. Edge router and firewall.
  3. VPN solution or bastion if it’s not included in the edge.

Each of these presents a major problem, but number one is the biggest for me. Registering your edge IP with public DNS or dynamic DNS is literally like putting a sign up that everyone on the internet can see your address. DNS is a prime target for every botnet and malware script kiddy on the internet. You may as well set off a beacon advertising the darkest parts of the web to come scan your ports. Try this with a honeypot and see how quickly you find yourself mining someone else’s Monero or worse.

Just invite attackers in, why not?

Number two is equally challenging. Given all the public attention you just brought on yourself, you’d better have a solid and reliable firewall and a connection that can handle a bit of DDoS flooding. If someone finds a vulnerable port on that IP you are automatically going to be registered with the next botnet hit list.

Welcome to Layer 4, where people check all your doors and window locks.

Number three presents a different problem. When you want to allow someone else access, most VPNs or bastion/jump hosts will expose the entire network by default, rather than just expose SSH to a cloud server or HTTP access to the local ARM server suddenly my collaborators have access to the entire network and all ports. Even without a VPN this can be a problem in corporate networks.

A gate to an entire network doesn’t do much good.

These same problems are faced by everyone from garage startups to tier 1 banks in the cloud. Boundary solves all of them in one universal package.

  1. Instead of public DNS, Boundary Controller provides a secure central point to configure identity, policy, host groups, and target endpoints. Nobody can find your edge IP without authentication and authorization. Instead of Dynamic DNS, Workers register themselves with the Controller and update themselves as IPs change. There are also no VPN credentials to hand out because users are authenticated by OIDC.
  2. Instead of firewall ports forwarding traffic which may or may not be encrypted, all traffic is proxied via the Boundary port, which automates mutual TLS between the client machine and the Boundary Worker.
  3. Instead of the VPN or bastion exposing my entire network, Boundary Worker replaces the VPN gateway and will only expose the IP/ports allowed by the Boundary Controller. Multiple Workers can be registered to the same Controller and multiple organizations can share a Controller since Controller supports multi-tenancy.

Sounds nice, right? So how complex is setup? Boundary Controller is a bit complex to set up from scratch. It requires a KMS or Vault to encrypt its data and a Postgres database. In accordance with the Tao of HashiCorp, it’s resilient and can be deployed as a single node or cluster. Even better, HCP makes it a snap to deploy, including automatic DNS and TLS certificates. We actually have a shared Controller in HCP for HashiCorp’s EMEA partners and each can have their own org to control.

What about Boundary Worker, which acts as edge gateways and monitors which hosts or host groups it has connectivity to? These also are resilient by design and can be deployed as single node or cluster. They can be deployed as cloud VMs or in a physical server with forwarding from the edge. Even better, our Go builds are extremely portable. I have found our ARM builds of Boundary Worker run just fine on commodity WiFi routers from ASUS, Ubiquiti, and more. They can be registered via PKI from the Boundary Controller locally or within HCP. If your router runs a Linux based kernel (most do) and has enough RAM (some do) then I find Boundary Worker generally will run on it just fine. Note that Boundary is currently only open source under an MPL2 license and there is no support from the Boundary team if your router crashes so please be careful and know it is at your own risk.

Results

I see Boundary as much more than PAM. Boundary combines the features of cloud service discovery, identity access control, and encrypted VPN in a way that makes remote working far simpler and secure than any previous solution. Here is a snapshot of my Organization within our EMEA Partners HCP Boundary Controller. It contains cloud and on-prem projects:

Multitenancy Controller showing Cloud and on-premise projects.

Within each logical project there are targets. In this case I’ve pinned the IP addresses to what I need but Boundary also has a powerful Host Groups feature to automatically discover services as IPs change which is helpful for cloud projects. Boundary can also let you know if no hosts are available for a host group.

Viewing Org->Project->Targets shows my services which I have explicitly pinned to an IP/port.

Now whenever I’m working remotely or someone needs access to a local resource all they need to do is authenticate with their Google account. This can be done via the CLI or via the Boundary Desktop app for Mac, Windows, or Fedora via mycross-built RPMs in COPR. Note the signing keys for my COPR repo are different from HashiCorp Engineering keys. Hopefully the packaging team will take over DEB/RPM builds soon.

Connect to a private GitLab from anywhere using Boundary Desktop. Perfect for remote working.

Now I can add users or groups of collaborators to Boundary Controller and map these users to the specific or dynamic target IPs and ports I need. It doesn’t matter if a team is working from an office or remotely from a beach. Identity and encryption will be verified from any network. For cloud or small office network, there is no big flag to hackers advertising ourselves on DNS and there is zero cost increase as Boundary Worker open source has replaced OpenVPN on the WIFI router. The Worker is registered via PKI. I’ve got this working on high end routers all the way down to a trusty old ASUS RT-AC68U.

Not just cloud VMs but even your old home router can serve as Worker connecting you to Boundary targets.

Conclusion

HashiCorp Vault has long been used for secrets management and partial access control but it is not a full PAM solution on its own. Some HashiCorp customers asked for more. Boundary delivers that and I think it far exceeds what I thought it would be. Boundary completes the Zero Trust suite from HashiCorp, combining Vault for dynamic secrets, Consul for dynamic service networking and mesh, and now Boundary for human-service access and PAM.

Like Vault, Boundary can be used everywhere from cloud to on-prem networks and I think it will catch on in much the same way. HCP can help you get started quickly and easily at low cost. In the meantime open source is already available for anyone to get started for free.

--

--

John Boero
HashiCorp Solutions Engineering Blog

I'm not here for popular opinion. I'm here for hard facts and future inevitability. Field CTO for Terasky. American expat in London with 20 years experience.