Zero trust Security using Hashicorp Boundary and Vault

In cloud environments, resources often reside in private networks. In traditional approaches, for developers or operators to access these resources, organizations often end up with VPNs or bastion hosts. Moreover, they also use static credentials for accessing these applications. But this approach has many challenges like scalability and eventually increases the attack surface.

In this context, I’ll discuss how HashiCorp Boundary and Vault come to the rescue and how their integration helps us achieve the core fundamental of zero trust security: “Trust Nothing. Authenticate and Authorize Everything. Boundary Vault Workflow

Traditional workflow for privileged access management (PAM)

Traditional workflow

Let’s say we have to access a private resource, it can be a database or a virtual machine and these machines reside on private datacenter on-premises or any private network of a cloud service provider.

Now a user, let’s take an example of a database administrator who wants to access the database in this private network, he is ideally not on the private network, they’re either working in their office or they’re working in their home.

  • VPN/Bastion Hosts: Now, if this user has to connect themselves to the private network, first of all, the organisations set up a VPN gateway or a bastion host. In case of VPN, they might get an IP address that puts them on the network, or in the case of bastion host, they need to get their SSH keys configured.

  • Firewalls: Once, we are inside the private network, we can literally access everything. So in practice, what we probably also do is, have some form of a firewall setup that’s going to restrict traffic. So, in our case, we’re going to create a firewall that says, ok, traffic can go from our bastion host or from our VPN to this database residing in the private network.

  • Application Credentials: And finally, once the user connects all the way through to the database, they also need a username and password to connect to it.

If we consider this workflow, you will notice that there’s a bunch of information the user needed. Firstly, the user needed to have VPN or SSH credentials. Secondly, they needed to know the IP or the host name to connect to. Then finally, they actually needed the database credentials to get all the way through to that system.

Challenges with traditional workflow

Challenges with Traditional workflow So, let’s see what are the challenges with this traditional workflow.

  • Onboarding/Off-boarding: The very first one being the onboarding and off-boarding of users. I don’t want to distribute VPN credentials and SSH keys to everyone who joins the company or everyone who leaves the company. This would definitely become a burden, especially if we consider best practices like key rotation on a regular interval.

  • Increasing the attack surface: Secondly, once the user has VPN access or access to Bastion Host, he/she literally has a wider network access thus increasing the attack surface. As seen in last slide, we will try to bring firewalls in order to mitigate this issue.

  • Managing IP’s in dynamic environment: Now this firewall setup is fine unless and until we have small number of static hosts where IP’s aren’t changing much but this wouldn’t scale when we have a highly dynamic infrastructure especially that auto-scales. Also, nowadays we are moving to ephemeral platforms like Kubernetes, where if a node dies, applications might be migrated to a different node. We’re also adopting more serverless things where you really don’t think about a host or a node or an IP anymore. It’s really about this logical service that you’re trying to route to. With all of these, we’re really moving away from relatively static infrastructure to much more dynamic infrastructure.

  • Static Credentials: Lastly, if I have to expose database credentials directly to my user, what happens if those get exposed or compromised somehow? I don’t want to have a static, long-lived credential that gets leaked. Someone might store it on their laptop, or they put it in a confluence doc which might be exposed to Internet, or they paste it into Slack conversations or might even get saved into a log file somewhere. Ideally why should I even give those credentials directly to an end user?. So, the question is how do we move away from static credentials and instead create a credential on-demand that’s short-lived and we revoke it when we don’t need it anymore? So there are a number of challenges in this workflow and if we have to move towards zero trust security philosophy wherein I really don’t have to trust my private network, I definitely need to do something differently.

How Boundary-Vault Integration comes to the rescue?

Boundary-Vault Integration So, let’s see how boundary vault integration solves all the challenges we discussed with the traditional workflow.

  • Authentication Using IDP: Firstly, with Boundary, every user is going to login through Identity provider. If your organization already uses Azure AD or Okta or any other IDP, the Boundary administrator can configure the same IDP for authentication. Once authenticated using this IDP, you prove that you are a valid user. Now, when we talk about on-boarding and off-boarding of users, it is just about adding or removing them from the IdP. There’s no additional step of distributing VPN or SSH credentials or rotation of SSH keys. Thus you solve the authentication very easily with Boundary.

  • Authorization based on roles: Now, once the user has actually authenticated, there’s going to be an authorization based on certain set of roles and permissions. So we’re going to have a role and that role is really going to drive role-based access control. For example in our case, our database administrators, they get access to the databases and Web developers get access to web tier. But we aren’t going to specify this role for a single host or a single IP, it’s actually going to be at the logical service because that’s what we really care about now. This is really important because the logical service lets us elevate from the details that are dynamic. You can basically differentiate between these logical services in a cloud service provider using tags like Azure tags, AWS tags. Database can have a database tag whereas as web tier can have a web tag. So if, the database administrators have to connect to the database, the set of databases can be dynamic, the IPs can come and go, they can change, they can be scaled up and down but the overall control stays the same.

  • Dynamic Services: Now, once the user sees his host, and clicks on Connect (we’’ see this in our upcoming demo), Boundary will directly establish a connection to the target system. 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.

  • Dynamic Credentials from vault: Finally, let’s talk about those scary static credentials. This is where Hashicorp Vault comes into picture. Hashicorp Vault is a secrets management tool from Hashicorp which is capable of generating dynamic and short-lived credentials through its different secret engines. These secret engines can generate dynamic credentials for any kind of a database, it can generate/rotate LDAP passwords for Active directory or it can even generate OTPs for linux machines. These credentials are tied to a TTL or in some cases can be used only once. Boundary integrates with Vault seamlessly to broker the credential which will then be used when the user connects to the target system using Boundary.

Demo to understand use-cases for accessing Windows & Linux using Boundary & Vault

I presented a talk on Zero Trust Security using Hashicorp Vault and Boundary in HashiTalks, 2023

  • Use Case 1 : Accessing Domain Joined Windows Servers using OpenLDAP secret engine
  • Use Case 2 : Accessing Linux servers with local accounts using SSH-OTP secret engine

Conclusion

Boundary-Vault Integration So, if we have to summarize this blog, you will notice that

  • Boundary users will authenticate to Boundary using an Identity provider.
  • Once authenticated, they will see only certain set of hosts or targets which they are authorized to see courtesy roles and permissions.
  • Finally they make a proxy connection to the target system using Boundary and gets the dynamic credentials for the target system from Hashicorp Vault. These set of credentials will either expire after certain TTL or can be configured to be used only once.