boundary

HashiCorp Boundary 0.1.5: Target-Aware Workers and More

What's new in Boundary 0.1.5

Boundary 0.1.5 has been released with several new features that make Boundary more capable in multi-datacenter and multi-region environments, drive more insights into Boundary’s resources by conveying what actions a user can perform on a resource, and allow a user to list resources recursively in scope. Additionally, we’ve added a new migrate command that provides an easier upgrade path with fail-safes in the event of migration issues. We’ll cover all these features in more detail below!

»Target-Aware Workers

The Boundary target-aware workers feature allows the ability to specify a boolean-expression filter against worker tags to control which workers are allowed to handle a given target’s session. This enables a worker to effectively be “tied” to a given target, forcing the session to occur through a specified worker for a specific target. This feature allows Boundary to be a key player in a multi-datacenter/multi-region cloud operating model by allowing a single set of controllers to live in one region, and then have workers in many regions where each set of workers can be tied to a specific network slice (VPC or other) where the targets they are proxying live.

HashiCorp Boundary Target Aware Workers

»Navigating Resources over the CLI

One of Boundary's biggest user asks has been to make it more straightforward to view and list resources on the command line. With 0.1.5 we’ve landed two improvements:

  1. List Authorizations - allowing users to see what actions they’re authorized to perform against the resources returned in the list command.
  2. Recursive Listing - allowing users to recursively list resources across a scope. Whereas users previously had to execute a series of boundary <resource> list -scope-id $project-id commands to survey their resources across all of their org’s projects, they now have a streamlined boundary <resource> list -scope-id $org-id -recursive to list all resources across an org.

In addition to being useful in their own right, these features are also foundational for future improvements in users’ abilities to filter and search for resources based on their parameters.

»Migrate Command

While new features are added to Boundary, like the Target-Aware workers, the backing database schema must be updated to support these features. The migrate command gives you a way to do that. Simply stop all the running controllers, run boundary database migrate and all the changes will be applied to the database in a single transaction.

Even though the migrate command is resilient to errors due to utilizing PostgreSQL transactions, it is still highly recommended that you follow good database practices and backup prior to migrating. This is also valuable in case you decide you want to stick with an older version of Boundary since the migrate command is a one-way switch that does not allow reverting back to an older version. In this release, and in future releases where new features require an update to the DB, boundary will not let you start a new controller but will direct you to use the boundary database migrate command.

»Next Steps

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.


Sign up for the latest HashiCorp news

By submitting this form, you acknowledge and agree that HashiCorp will process your personal information in accordance with the Privacy Policy.