Announcing HashiCorp Boundary

We are pleased to announce HashiCorp Boundary, a new open source project that enables practitioners and operators to securely access dynamic hosts and services with fine-grained authorization without requiring direct network access.

Boundary is designed to grant access to critical systems using the principle of least privilege, solving challenges organizations encounter when users need to securely access applications and machines. Traditional products that grant access to systems are cumbersome, painful to maintain, or are black boxes lacking extensible APIs. Boundary allows authenticated and authorized users to access secure systems in private networks without granting access to the larger network where those systems reside.

»Traditional Workflow

To better understand how Boundary works, and why we are building it, we want to provide a few examples that highlight the challenges users and operators face when securely connecting to applications and critical systems.

The diagram below illustrates a typical connection workflow and the challenges that occur when a user requires remote access to a production system located in a private network. Usually a gateway bridges access into these private networks through a VPN or SSH bastion host. Both solutions offer varying degrees of security which could provide a user with direct access on the private network and not just access to the intended systems.

This traditional access model assumes resources are mostly static, and it is not well suited for the cloud with highly ephemeral and dynamic environments. Scaling the solutions as workforces and infrastructure grow creates additional pain points and complexity for administrators to manage.

Once users are on these private networks, they can access any system and not just the intended target. If the credentials used to access the VPN or SSH host are lost or stolen, an adversary could access the entire network. To safeguard against that risk, a traditional workflow will typically place a firewall inside these private networks that restricts what users have access to in order to safeguard against this risk.

However, managing internal firewalls is time consuming and wasteful when the system granting access should have followed the principle of least privilege from the outset. Boundary was designed with these core problems in mind: grant access to critical systems with least privilege.

»Boundary Workflow

The goal of Boundary is to simplify the workflow for securely accessing hosts and services while also reducing risk and attack surface associated with traditional solutions. With Boundary, access is based on the trusted identity of the user, rather than their network location. The user connects and authenticates to Boundary, then based on their assigned roles they can connect to available hosts, services, or cloud resources.

Trusted identities and roles are a core principle in Boundary; they define which users are allowed to connect with a specific set of resources. For example, with Boundary, you could grant only developers access to connect to databases. This model allows Boundary to define logical sets of systems and applications and removes the brittleness associated with static IP addresses.

Boundary authenticates and authorizes each request, mapping users to services or hosts at the application layer. There are no VPN credentials or SSH bastion host keys to manage, which simplifies onboarding and reduces risk of a credential compromise.

Boundary provides an easy-to-use, platform-agnostic way to access all of your hosts and services across clouds, Kubernetes or Nomad clusters, and on-premises datacenters through a single workflow based on trusted identity. It lets you remove hard-coded credentials and firewall rules, and makes access control more dynamic.

»How Boundary Works

Boundary 0.1 enables authenticated and authorized TCP sessions to applications with role-based access controls (RBAC). Users can automate access management to dynamic targets with the Boundary Terraform provider, the API, or SDK. Boundary also supports monitoring and logging of session metadata.

We designed the architecture of Boundary to be easy to understand, highly scalable, and fault tolerant. Users can interact with Boundary through the CLI, API, or a web interface. It can run on-premises, in the cloud, or in secure enclaves, and it does not require you to install an agent on target hosts.

To better explain how Boundary works, let's walk through how an end-to-end connection is established. When a user authenticates to Boundary, they can choose from a selection of hosts or applications based on their roles, and then connect through Boundary to access those hosts or applications.

When a user establishes a TCP session through Boundary, a Boundary worker node seamlessly proxies the connection. This makes Boundary more secure than traditional access systems such as a VPN or SSH bastion hosts because Boundary makes the connection for the user and limits the user’s access. Since Boundary controls access directly for end users, all the way to the intended target system, it makes your organization’s network more secure by never allowing users access to the private network.

»Next Steps

Boundary 0.1 is available today as an open source project. Note that the project is under active development and we are working on adding OIDC authentication, a HashiCorp Vault integration, and dynamic target catalogs pulled from HashiCorp Consul, AWS, Azure, and GCP.

To learn more about Boundary, please visit the project website at boundaryproject.io, github.com/hashicorp/boundary for the source code, and HashiCorp Learn to find our step-by-step tutorials to get started with Boundary.

If you experience any issues, please report them on the Boundary GitHub issue tracker or post to the Boundary discuss forum. We hope you enjoy Boundary 0.1.