We built HashiCorp Boundary to make it simple to grant and maintain access to infrastructure. Today, developers, operators, and security teams struggle to maintain access controls for on-premises and cloud infrastructure. Even though the systems these teams interact with are more automated and extensible than ever, granting a human access to a VM, a database, a container, or any remote system is still difficult at scale.
Part of the reason that human access to machines is still a hard problem is that traditional solutions are heavy, opaque, or inextensible. They’re missing the open-source values that help software projects improve and grow. To this end, we developed Boundary with HashiCorp’s core principles in mind.
We want Boundary to be:
Boundary was born out of feedback from you, our end users. For years, HashiCorp Vault users requested we build a feature that could grant secure sessions to remote systems. We gave this consideration a lot of thought and concluded that Vault’s primary domain was credential management whereas the tool being requested was primarily about session management. Not to fit a square peg in a round hole, we decided that such a tool should stand on its own and the concept of HashiCorp Boundary was born.
Though the concept began much earlier, the actual decision to build didn’t happen until late 2019. Over the course of 6 months beginning in the fall of 2019, Jeff Mitchell and Andy Manoske developed the vision for Boundary. They researched the market and began building a team that would eventually become the core contributors for the HashiCorp Boundary Project.
From the Fall of 2019 through the Spring of 2020, a team of senior engineers was assembled: Mike Gaffney, Jim Lambert, and Todd Knight joined the backend team; Randy Morey and Susmitha Girumala joined the frontend team, and I joined from the Vault project as the engineering manager. In the summer of 2020, Pete Pacent joined HashiCorp as our first product manager.
Request for Comments (RFC) documents are the guiding light of any project at HashiCorp. In the product's early days we did more wordsmithing than coding, occasionally prototyping our ideas to make sure they made sense.
By late May of 2020, with a tightly scoped minimum viable product (MVP) in hand, we began writing HashiCorp Boundary in earnest. We had 6 months to build an MVP and 6 sets of hands to do it. One month before launch, we had a working end-to-end product that included:
As described in our public roadmap, in the near term we plan on shipping an OIDC auth method, transparent credential management with a HashiCorp Vault integration, dynamic host discovery for popular platforms, and a desktop client to make session establishment and management a seamless user experience.
Authentication is an important aspect of any software project, and we believe the lowest common denominator for authentication today is OpenID Connect. OIDC is a mature framework supported by major identity providers. For this reason, we chose it as our second auth method beyond passwords to give you the ability to bring your own identity to HashiCorp Boundary.
We know that a big piece of access management is credential management. Nobody wants to maintain multiple passwords or keys. HashiCorp Vault has the ability to manage credentials for major cloud platforms, databases, and other technologies that play a pivotal role in modern web applications. By integrating with Vault's dynamic secrets capability, Boundary can broker on behalf of users, and eventually inject, credentials into their Boundary sessions. We can expose these brokered credentials to users or we can transparently inject them and never expose any sensitive information. Both use cases are high on our road map, and we’re excited about the opportunity this integration will bring to the Boundary story.
Host catalogs are a central concept to Boundary and a differentiator when comparing Boundary to other access management solutions. Today, Boundary only has static host catalogs: users have to construct a host definition manually. However, the original intent for host catalogs was to allow dynamic discovery of hosts based on modern groupings such as Kubernetes constraints, security group assignment, labels, or other collection types common in today’s dynamic cloud and container environments.
We plan to bring dynamic host catalogs to life over the coming year for major cloud and container platforms. This will allow administrators the ability to grant access to users based on abstractions rather than hard coded CIDR ranges and IP addresses, making Boundary easy to set up and maintain.
Finally, to make the user experience for session management awesome, we plan to build a desktop client for Windows and Mac. This will allow users who are not comfortable with the command line or who simply want a more graphical interface for Boundary to start and manage sessions to targets.
Of course, the development of these features will be executed in parallel with reviewing contributions from you, our community.
We would not be here today without your feedback. We look forward to hearing from you, seeing your pull requests, and helping you work through any issues that invariably arise with an early software project. Most importantly, we want to build a product that solves real-world challenges you and your team are facing in managing secure access to critical systems.
We will be organizing a HashiCraft Holidays Hackstravaganza where you and your fellow tinkerers can use your creativity to showcase one or more of our products in creative and unexpected ways.
In this blog, we round-up all of the KubeCon related activities HashiCorp will be doing this week at the virtual conference and adjacent to it.
Learn how the domain model works in HashiCorp Boundary and how it approaches IAM.