HashiCorp Boundary 0.4.0 and Boundary Desktop 1.2.0 includes features supporting brokering of HashiCorp Vault secrets for Boundary targets to end-users, enhanced session cleanup, and foundational features for event logging.
From the beginning, HashiCorp Boundary has promised to streamline access management. Since Boundary’s launch eight months ago, we have openly discussed integration with HashiCorp Vault as a primary focus of our immediate road map. Today, we are thrilled to announce Boundary 0.4, which adds a Vault integration for the brokering of Vault secrets to Boundary clients (both command line and desktop clients) for use in Boundary sessions.
Screenshot: Boundary target connection details.
Brokering of Vault secrets is the foundation of Boundary’s larger credential-management story for seamless single sign-on to infrastructure targets. This feature involved the development of new Boundary resources to support binding credentials with user sessions, as well as surfacing those credentials during session initialization on the command line and in Boundary Desktop.
Users can configure Vault credential libraries and Vault credential stores through our Terraform Provider and command-line interface, and we will be shipping the ability to do this through our administrative console soon. Along with having the ability to receive the credential for a given session through the desktop client, we have made a seamless integration with the
psql command line wrapper during connect which will automatically inject credentials into a session on the command line when connecting with the postgres wrapper via
boundary connect postgres.
To get started with this using Boundary sessions, please check out this HashiCorp Learn tutorial.
We are also working to tighten the behavior of how sessions are handled during periods of degraded performance.
Consider a scenario in which a worker loses its connection to the controller, or vice versa. In these events, vital communication regarding the validity of a session is lost, and as such, we cannot know if a connection should reasonably continue. Following the principle of least privilege, it behooves Boundary to ensure that such connections cannot continue in the absence of that data.
These enhancements are being introduced, starting in Boundary 0.4, with logic on the worker side to shut down all connections in the event of a failure to contact the controller after a short period of time. Additional enhancements will be coming in 0.4's minor releases, including controller-side logic to mirror the worker enhancements, synchronization of connection expiry times to the database, and additional behavior on shutdown to not only ensure the connections themselves are closed, but that the state of the connections is correctly cleaned up.
As always, we recommend upgrading and testing this release in an isolated environment. If you experience any issues, please report them on the Boundary GitHub issue tracker or post to the Boundary discussion forum. As a reminder, if you believe you have found a security issue in Boundary, please responsibly disclose it by emailing firstname.lastname@example.org — do not use the public issue tracker. Our security policy and our PGP key can be found on the HashiCorp security page.
We hope you enjoy Boundary 0.4!
If you’re attending AWS re:Invent in Las Vegas, Nov. 27 - Dec. 1, visit us for breakout sessions, expert talks, and product demos to learn how to accelerate your adoption of a cloud operating model.
See a potential method for securing application content and components hosted within Kubernetes using Boundary as an alternative to ingress controllers.
From AI to the edge, HashiCorp Co-Founder and CTO Armon Dadgar shares his insights on where the cloud is headed, and what that means.