It only seems 5 minutes ago that Hashicorp released Boundary at their October 2020 Hashiconf online extravaganza. But like the rest of their products, it evolves at a serious pace.
Quick recap – what is Boundary
In a world dominated by VPNs and SSH which require a method of distributing and managing credentials, configuration of network controls like firewalls and the exposure of the private network, Boundary was designed to provide a secure way to access internal resources and other critical systems without having to manage credentials or expose your network in any way. Also like all of HashiCorp’s tooling, it is entirely opensource.
Boundary can interface with trusted Identity providers like Git, IAM, Azure AD, okta etc to authorize access based on role and services, rather than based on physical IP addresses that are required with SSH or VPNs, and for belt and braces, it can interact with Hashicorp Vault to automate credential injection to securely access services and hosts using Vault.
Ok, so now we have an idea about Boundary, what is new with 0.1.5?
What’s New
The latest version of BoundaryThas included a number of new enhancements to enhance its capability in multi-datacenters and or multi-region or cross-cloud environments. Further, there are improvements in monitoring and also accessibility, regarding the ability of a user to see what resources are available to them. And finally, the addition of a migrate command to provide a safer upgrade path. We will now discuss these new features in deeper depth.
Target-Aware Workers in Boundary
HashiCorp has called their first feature Target-Aware workers, this feature will allow the addition of a Boolean expression filter against worker tags to control which workers are enabled to handle specific target sessions. Sounds impressive but what exactly does it mean?
It effectively enables a worker to be tied to a specified target, for example where Country specific compliance is required, the worker will be tied to a region in the desired region or data center. You could say in this mode Boundary is acting in a similar manner to a VPN, allowing direct access to a single resource, for example, a jump box; or region, for example, an AWS VPC. This can significantly reduce cloud networking complexity it can also increase security by tying a user or group of users to a single point of entry, whilst still protecting against credential transfer. Effectively the best of both worlds. To deploy this in your datacenters or multi-regional cloud environments you would deploy a single set of controllers in your core region and then deploy the requisite workers in each region which are then tied to a specific network segment where the resources they are proxying reside.
Navigating Resources over the CLI in Boundary
According to HashiCorp, this new feature is one of Boundary’s biggest requests. The ability to simplify the ability to view and list resources from the command line. This release has added the following two product enhancements.
- List Authorizations– this allows users to see what actions they are authorized to perform against the list of resources returned by the use of the list command.
- Recursive Listing– this allows users to recursively list resources across a scope. Previously users had to execute Boundary <resource> list -scope-id $project-id commands several times to divine their resource authorizations across all of their org’s projects, now users have the streamlined Boundary <resource> list -scope-id $org-id -recursive which will list all resources across an org.
Unfortunately, if users have access to multiple organizations they will still need to issue extra commands to confirm their entire list of authorizations, but it is a step in the right direction. And it is easy to define the direction HashiCorp are moving with this command as it lays the foundations for greater improvements on filtering and search capabilities based on imputed parameters.
Boundary’s new Migrate Command
The final feature we will be looking at is the Migrate feature. Although it is nice to have new features, to support them requires an update to the Boundary Database schema. Messing with schemas always worries me, it appears that it also worries Hashicorp too. The migrate command give you a supported method of upgrading the schema when upgrading versions. This streamlines the upgrade process down to a single transaction.
Now a word of warning, just because the Migrate command is resilient to errors as it wraps PostgreSQL transactions, you are still recommended to follow good database husbandry practices including verifying your backups are up to date and more importantly capable of restoration prior to issuing the command. This is because the use of the Migrate command is a one-way street. There is no capability to revert the command once issued and completed, if a legacy Boundary controller attempts to start there will be a warning issued directing the use of the migrate command to update this instance. This is important to understand as HashiCorp has advised that anytime new features are added to the product, there will be a requirement to update the back-end DB schema, once this decision has been made all controllers will need to be updated.
Summary
Even though this was only a 0.1.x release, there is a significant amount of changes and enhancements, this is par for the course with HashiCorp, who tend to have a hidden defined roadmap to their 1.0 release. That can be several months or even years down the path. They tend to release their products as an MVP and then rapidly release small cumulative updates to enhance features. This is completely inline with the DevOps ethos.
To me the introduction of the Migrate command is the most interesting feature. Yes, the additional features are nice, but the Migrate capability points to a period of rapid enhancement, their pointed comments about things being a one-way street leads me to feel that we will be seeing some serious enhancements over the next couple of months.
