Empowering Credential Injection at scale using HashiCorp Boundary

In cloud environments, if we have to move towards zero trust security philosophy, we need to bring HashCorp Boundary and Vault integration into play.

Boundary is an identity-aware proxy solution that provides a simple, secure way to access hosts and critical systems on your network and Vault is HashiCorp’s comprehensive secrets management solution. The typical workflow would be like:

• The Boundary user, through CLI/Desktop app, authenticates to Boundary Control Plane using an identity provider.
• Once authenticated, based on their role in the organization, they are shown certain targets which they can connect to.
• Once they connect to a target, the Boundary Control Plane gets the required dynamic credentials from Hashicorp Vault.
• These dynamic credentials are either brokered or injected in Boundary workers and a proxy connection is made to the target.

One of the key advantages of this approach is that you will not be specifically bridging the client onto the private network, so, we stay in line with sort of a zero-trust network philosophy where we’re not bridging users onto this private network.

However, as with any technology, adopting and scaling Boundary across large or complex environments comes with its own set of challenges.

Let’s take a quick look at some of these challenges. So, during adoption phase, you’ll notice that the credentials are still exposed to the users in case they’re using credential brokering feature or they still end up leveraging static SSH keys from Vault’s KV secret engine. Whereas during scaling phase, you often struggle with accountability and traceability issues in case of shared-user Linux accounts. Also, you might see some resource sprawling in case of multi-user Linux accounts. And then we can’t forget about automating these Boundary and host configurations when you’re talking about thousands of machines which you need to manage.

Challenge 1 : Credentials still exposed to the users

Organizations often using Boundary OSS rely on credential brokering. However, this approach lacks the ability to fully hide credentials from users. When a user attempts to connect to a target, Boundary’s control plane retrieves the necessary credential from Vault. Unfortunately, this credential is then visible to the user, allowing them to copy and use it to connect to the target. Even if the credential is dynamically generated, it is still exposed to the user, which poses potential security risks.

This is where credential injection comes into play. As part of this feature, when a user attempts to connect to a target, Boundary’s control plane retrieves the necessary credential from Vault. But this time, instead of exposing credentials to the user, the Boundary control plane directly injects the credential to the worker and the session is established. This gives a passwordless experience to the user. This is an Enterprise/HCP only feature.

Challenge 2 : Using static SSH keys from Vault’s KV secret engine

We can solve this issue with SSH certificates. With SSH certificates, the user’s authenticity is based on possession of a certificate signed by the trusted certificate authority (CA). Instead of having to provision and deprovision keys across your infrastructure, SSH certificates allow you to specify how long a certificate is valid for or which users the certificate holder can login as. In this workflow:

• Boundary generates SSH key-pair and sends to Vault
• Vault signs the certificate and sends back to Boundary control plane
• Control plane injects credentials to worker

Demo for passwordless authentication

Please follow the demo in below talk which I presented during HashiConf 2024 in Boston.

From an organization’s perspective, there may be good reasons for sharing usernames on the hosts, such as making it easier to configure unix permissions, configuring common reusable scripts, resource limits or maybe simplifying the overall provisioning of the hosts.

• Different Boundary users are authenticating using one single shared-user.
• A single credential library is created in a credential store with shared user as username. This causes accountability and traceability issues.

To solve this, you can enable SSH Recording feature.

• With SSH Session Recording feature, every session recording will be associated with a user.
• Create a storage bucket with a given provider and then enable session recording at target level.

Challenge 4 : Resource sprawling issues with multi-user Linux accounts

I have created a dedicated blog on this issue.

Challenge 5 : Struggling with automating configurations?

• With credential injection, you need to add public key of CA (Hashicorp Vault) in every host/target.
• Creating Boundary projects, targets, credential stores and libraries can be difficult while scaling.

To solve this:

• Use HashiCorp Packer to create golden images with public key of Vault (as a CA), embedded in the image.
• Use HashiCorp Terraform’s Boundary provider to configure all resources within Boundary.

Conclusion

So, if we have to summarize this blog, in order to introduce a robust solution for dynamically creating and managing SSH certificates at scale, you need to:

• Enable SSH Certificates in HashiCorp Vault.
• Use HashiCorp Packer to embed the public key of CA in the golden image to spin up the SSH machines.
• Use HashiCorp Terraform to automate all Boundary configurations.
• Enable dynamic credential templating for credential libraries.
• Introduce SSH credential injection.
• Enable SSH recording for all SSH targets.