Boundary 0.12 introduces multi-hop sessions and SSH certificate injection

We’re excited to announce the release of HashiCorp Boundary 0.12, now available in HCP Boundary and for open source download. Boundary provides identity-based remote access to infrastructure for individuals and teams operating at any scale.

The 0.12 release adds major new functionality to Boundary, including:

• Multi-hop sessions (HCP-only): Boundary can now establish sessions to targets through multiple-hops of workers secured through reverse-proxy. This eliminates the need to expose workers on private networks, enclaves, and disconnected networks directly to clients.
• Credential injection using Vault SSH signed certificates (HCP-only): Boundary can now inject single-use SSH certificates generated by HashiCorp Vault to increase protection for SSH targets.
• Addresses on targets: Administrators can now optionally assign a network address directly on a target, eliminating the requirement of attaching a host.
• Credential templating: Vault credentials can now be mapped directly to a user within a target instead of needing separate targets per user credential.
• Key lifecycle management (OSS-only): You can now manage the lifecycles of both key encryption keys (KEKs) and data encryption keys (DEKs) using the new key rotation and key version destruction functionality.
• JSON credentials: Administrators can now create and broker JSON blobs to authorized users connecting to machines. This allows more flexibility in the credentials that can be brokered.
• Authentication UX improvements: Users no longer need to provide an auth method ID in the command line during authentication. If none is provided, the “primary” auth method ID will be used.

»Multi-hop worker sessions (HCP)

Boundary workers can be deployed in any public or private network to enable secure access to infrastructure resources. Prior to Boundary 0.12, the workers were required to have outbound network access to the HCP Boundary control plane, and they needed to have inbound network access from clients in order to establish sessions. However, many organizations do not allow any inbound access to their private networks, which means remote users would need to be on the same corporate network or use a VPN solution in order to reach the Boundary worker.

In Boundary version 0.12, we are introducing a new feature called multi-hop sessions, which allow sessions to be proxied over multiple workers chained together through reverse-proxy connections. This means that a worker in a private network would only require outbound network access to reach upstream workers or the control plane. Remote users no longer need to have network access to the private network. Instead, they just need network access to the client-facing (or ingress) worker.

As depicted in the diagram above, there are two main options to achieve an outbound-only session with HCP Boundary and multi-hop sessions:

1. Use one of HCP Boundary’s publicly available workers as a client-facing worker for users to connect to.
2. Set up publicly accessible workers in a corporate network for users to connect to, acting as a public bastion host.

In addition, multiple workers can connect together to form a chain that can reach inside enclaves. For example, if there is a Kubernetes cluster inside of a datacenter network typically accessed from a bastion host on the corporate network, a chain can be established so that a remote user only needs to authenticate to Boundary once. Boundary can securely connect users to the requested target on the appropriate network.

Learn more about multi-hop in our tutorial and documentation.

»Credential injection using Vault SSH certificates (HCP)

Starting in Boundary 0.10, users could create sessions with injected SSH private keys, as well as usernames and passwords. Injected credentials are an improvement over traditional brokered credentials because they are never returned to user devices and are instead injected into a session on worker nodes through protocol decoding. However, SSH private key and username/password injection methods still faced operational and security limitations.

With public key authentication, keys for each user need to be distributed to all of the correct hosts. Additionally, both private key and usernames/password injection rely on the use of static credentials. In contrast, SSH certificates can be used to generate unique credentials for each session and only require administrators to distribute a certificate authority’s (CA) public key to the hosts. Boundary users have asked for SSH certificate support, allowing them to provide Boundary with a public key and have a CA that’s connected to Boundary return a unique signed certificate for each session.

Traditionally, users have worked around Boundary’s lack of SSH signed certificate support by exposing Vault and bastion hosts to end users so that they can retrieve a signed certificate from Vault, which then allows connectivity to the bastion host.

In Boundary 0.12, we’ve added support for credential injection of Vault SSH certificates. By leveraging Boundary’s integration with the Vault SSH secrets engine, you’ll be able to use Vault as your certificate authority for SSH certificates.

Boundary administrators can use either the issue or sign endpoints to generate certificates from Vault. This gives users a secure way to connect to SSH endpoints with credentials that are both dynamic _and _injected into a session so that users never see the credentials.

Learn more about certificate injection in our tutorial and documentation.

»Addresses on targets

HashiCorp Boundary offers an extensible domain model that allows administrators to organize target resources in a way that complements how their organization prefers to manage its infrastructure. However that flexibility can become a hindrance when it comes to setting up a quick proof-of-concept and defining a target in order to create a session.

Boundary 0.12 introduces a quicker way to set up a target. Traditionally, a user would need to define hosts within a host set and then assign that to a target. The hosts contain the hostname or IP address of the computing resources that the user would like to connect to, and the target definition contains various connection parameters to those hosts.

Starting with 0.12 users can specify the hostname/IP address directly within the target definition, negating the need to create hosts, host sets, or host catalogs. This functionality allows a user to get started with Boundary quickly while maintaining the same level of flexibility for more complex and production-like scenarios.

For more information, refer to the Target and host resources documentation.

»Credential templating for Vault paths (0.11.1)

Before credential templating in Boundary, if an administrator wanted to map credentials associated with specific users, they were forced to create individual targets and credential libraries for each user for the same host. This leads to resource sprawl within Boundary, resulting in hundreds to thousands of individual credential libraries at scale.

The table below shows an example list of per-user credentials for access to a common host. Before credential templating, administrators had to set up targets for each user.

In Boundary 0.12, we’ve added support for credential templating within credential libraries. This allows administrators to configure one target with one credential library that generates per-user credentials.

The table below shows an example list for setting up a single target with unique credentials for each user through credential templating. Administrators no longer need to maintain targets for each user.

Users can perform credential templating based on:

• {{.User.Id}} - The user's ID.
• {{.User.Name}} - The user's name from the user resource.
• {{.User.FullName}} - The user's name from the account corresponding to the primary auth method in the user's scope. This value may be unpopulated or different from the account name used in the template.
• {{.User.Email}} - The user's email address from the account corresponding to the primary auth method in the user's scope. This value may be unpopulated, or it may be different from the account name used in the template.
• {{.Account.Id}} - The account's ID.
• {{.Account.Name}} - The name of the account from the account resource.
• {{.Account.LoginName}} - The account's login name, if a login name is used by that type of account.
• {{.Account.Subject}} - The account's subject, if a subject is used by that type of account.
• {{.Account.Email}} - The account's email, if email is used by that type of account.

For more information, refer to the Vault credential library parameter templating documentation.

»Key lifecycle management (Boundary 0.11.1)

You can now manage the lifecycles of both KEKs and DEKs using the new key rotation and key version destruction functionality.

When rotating the keys, Boundary creates a new key version for the KEK and all DEKs in the specified scope. These new key versions are used for future encryption operations, while the older key versions may still be used for decrypting existing data in the database. It is considered a best practice to regularly rotate encryption keys to lessen the impact of key compromise, among other factors.

In addition to creating a new key version for all keys in the scope, you can optionally use the rotate key command to re-encrypt existing key versions with the new KEK version so all DEK versions, both old and new, are encrypted using the new KEK version.

For more information, refer to our Key version lifecycle management documentation and the Boundary KMS root key migration blog post.

»JSON credentials

Up to Boundary 0.11, Boundary’s static credential store supports only two static credential types: username/password and SSH private key types. With Boundary 0.12, we’re introducing a new JSON credential type to the static credential store.

Administrators can now create and broker JSON blobs to authorized users connecting to machines. This allows for more flexibility in the credentials that can be brokered.

»Auth method improvements

Previously, authenticating through the CLI required you to provide an auth method ID. This value is sometimes difficult to find, if you did not previously save the ID. Starting in version 0.12, the Boundary CLI no longer requires you to provide an auth method ID and will use the default auth method ID if none is provided. The built-in password auth method is now marked as “Primary” when an HCP Boundary cluster is deployed.

»Get started with Boundary 0.12

For more information about the new features and improvements introduced in Boundary 0.12, please see the release notes and 0.12 CVE fix.

If you’re new to HashiCorp Boundary, get up and running quickly with our Get started with Boundary tutorial. If you’d like to try the managed version of Boundary on the HashiCorp Cloud Platform, check out HCP Boundary with our free trial.