Transcript
HashiCorp Boundary emerges as a game changer. Today in my talk, we'll explore the art and science in the realm of password vault management within HashiCorp Boundary. I'll try to dissect some best practices, offering practical insights into configuring, securing, and optimizing the native password vault in HashiCorp Boundary, and how organizations can leverage HashiCorp Boundary to secure critical credentials, streamline access workflows, and fortify their overall security infrastructure. My name is Jameet Sahani. I'm a cloud and DevSecOps consultant. I'm a HashiCorp Boundary co-contributor and a big advocate of HashiCorp tools since a long time. Now let's start with our talk. Before we jump onto the main topic of my today's talk, for people who are new to HashiCorp Boundary landscape, I would like to quickly do a recap of how you can achieve zero trust security using the same. We'll understand the challenges of traditional workflow for privilege access management, followed by how we solve these challenges using Boundary and Vault. For more context, do visit my HashiTalk from the last year, where I've demonstrated a couple of use cases for accessing Windows and Linux-based servers using Boundary and dynamic credentials generated by Vault. So let's see what a traditional workflow for PAM looks like and what are the challenges associated with them. 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 are either working in their office or they are working from their homes, right? Now, if this user has to connect themselves to private network, first of all, all the organizations have to set up a VPN gateway or bastion host. But here we would have the challenge of onboarding and offboarding the users. Now, once we have connected to the VPN or bastion host, now we are inside the private network. The user can literally access everything, thus increasing the attack surface. So in practice, what we probably also do is have some form of firewall setup that's going to restrict the traffic. Now, the firewall setup is fine unless and until we have a small number of static hosts where IPs aren't changing much. But this wouldn't scale when we have a highly dynamic infrastructure, especially that auto scales. Now, finally, once the user connects all the way through to the database, they also need a username and a password to connect to it. But 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 static long-lived credentials that get leaked. Now, 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 database. So there are a number of challenges in this workflow. And if we have to move towards zero trust security philosophy, which basically means trust nothing, authenticate and authorize everything, I definitely need to do something differently. This is where boundary and vault integration comes to a rescue. Let's see what happens here. Firstly, with boundary, every user is going to log in through an identity provider. So once we are authenticated using this IDP, you prove that you are a valid user. Now, when we talk about onboarding and offboarding of user, it's just about adding or removing them from the IDP. Now, once the user has authenticated, there's going to be an authorization based on certain set of roles and permissions. So we are going to have a role, and that role is really going to drive the role-based access control. But we aren't going to specify this role for a single host or a single IDP. It's actually going to be a 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. Now, the user tries to connect to that particular host or service. Now, 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 the line with sort of a zero trust network philosophy where we are not bridging users onto this private network. Finally, let's talk about those static credentials. This is where HashiCorp Vaults comes into picture. HashiCorp Vaults is a secrets management tool which is capable of generating dynamic and short-lived credentials through its different secret engines. The secret engines can generate dynamic credentials for any kind of a database. It can generate, rotate LDAP passwords for an active directory, or it can even generate OTPs for the Linux machines. So Boundary integrates with Vaults seamlessly to broker the credential which will then be used when the user connects to the target using the Boundary. Now, let's see what credential stores are basically in Boundary. A credential store is a component within Boundary that securely manages and stores credentials used for accessing systems, applications, or services. In Boundary, we have two different types of credential stores. One is HashiCorp Vault and the other one is a static credential store. HashiCorp Vault, as we discussed earlier, is a comprehensive secrets management solution and aligns with the philosophy of zero trust security. It gives you the ability of using short-lived dynamic secrets based on predefined policies. On the other hand, for a static credential store, credentials are manually managed within Boundary and it's only meant for long-lived static credentials. So the next question would be when to use Boundary's static credential store? Well, let's look into some scenarios where it might be helpful. Firstly, when your organization doesn't have any secrets management solution yet like HashiCorp Vault, go for this credential store. Secondly, if your organization is looking for an easy onboarding without getting into any kind of operational overhead in managing systems like Vault, go for this credential store. Next one is pretty straightforward. Only if your use case requires static long-lived credentials, then go for such a kind of a credential store. Remember, this store doesn't have any capabilities of dynamic secrets. Last but not the least, if your organization is looking to have one single user interface for all operations like boxing to target servers or accessing static secrets, then Boundary's static credential store could be a good choice. Let's see what different kinds of use cases we can achieve using this static credential store. Let's start with passwordless authentication. This feature is an enterprise-only feature and is available in HCP Boundary and Boundary Enterprise. Unfortunately, this isn't part of Boundary OSS. So using Boundary's credential injection feature for SSH targets, the user never sees the credentials required to authenticate to the target. In a way, it provides a passwordless experience for the user. As a worker, it does both session establishment and the authentication to the target on the behalf of the user. So for this use case, the static credentials for the targets will be stored in Boundary's static credential store. So the workflow would be something like this. The user is going to authenticate to the Boundary. He is going to request a connection to the SSH target. The controller fetches the credential from the credential store and the user establishes session using the embedded terminal. Now let's see this feature through a quick demo. So in our case, what I've done is I've created an HCP Boundary clusters because we wanted to make use of credential injection, which is an enterprise feature. This is my Boundary UI. So I've logged in as an admin. I've created a Hashtag organization and I've created a credential injection project. So in this project, if you see here, I have a credential store. This is basically a collection of credentials and libraries. So you can see two different types of stores. One is a static and the other one is a void. So for our use case today, I've created a demo static credential store. In this credential, I have two different types of credentials. One is a username and a password kind of a credential and the other one is a username and key pair. You can also have a JSON kind of a credential. So one username and password and the other one is a username and key pair. So I've created two targets. One is an AWS target. For this AWS target, what I've used is it's a SSH type of target and it supports credential injection, which is an enterprise feature. OK, so what I've done is I've in this particular target, I've injected a credential, which was of type username and key pair. Similarly, I have a zero target. Again, it's an SSH type of a target, which is only available with enterprise feature and it has a username and a password kind of a credential attachment. Now, this is the boundary desktop. Now in this boundary desktop, if I connect to the AWS target now, right, and if I go to the embedded terminal, this is again one of the features which was recently launched. I see that I'm automatically logged in into my AWS target as an EC2 user. I'm going to end this session and maybe try to connect to an Azure target this time. So if I connect to an Azure target, again, I'll be using the embedded terminal here and you will see that I'm logged in into my Azure target. And if I see I'm logged in as my JSON user. So that was a quick demo on the credential injection feature. Next use case will be focused on boundary acting as a static server where users can view, create, update, or delete credentials based on their roles. And these static credential stores can lie in different boundary projects to provide a clear separation of concerns for each business unit or a team. Let's see what kind of roles or personas we can have for this use case. First persona is going to be a password administrator who will have the ability to create, update, and delete credentials. And this user is going to use boundary UI for the same. The second persona will be of a password user who only has the ability to view the credentials created by the administrator. And this user will use boundary desktop application for viewing the credentials. Let's see how the workflow would look like for this particular use case. So I'll have a boundary administrator who is going to use a Terraform for automating all the configurations. So all the users, managed groups, static groups are going to be onboarded using Terraform. The projects, credential stores, and targets are going to be created for each of those teams. And then finally, I'm going to define the roles for the password users and the password administrators which we discussed in the last slide. Now the password administrator persona, right, this person or this user is going to use boundary UI in order to create, update, delete credentials in a credential store. And then these credentials are mapped to the targets. Finally, the password user is going to use boundary desktop app. He's going to connect to the authorized target and then copy or view the credentials after establishing a session. So let's see this feature through a quick demo. So in this demo, what I'm doing is I am going to onboard two different teams. One is CloudOps and the other one is SecOps, right? So in this, for CloudOps team, I'm going to create four different types of groups, two for each of the teams, right? And user one is going to be a CloudOps admin, user two is going to be a CloudOps user, user three and user four, so on. Okay. And then there will be like four groups corresponding to this. Now what I'm going to do is I'm going to create a mapping between these groups. I'm going to onboard these groups using Terraform, all the four groups which we discussed. And then for every team, I'm going to onboard every team in a different project using this variable. So I'm going to create, for every team, I'm going to create a project, a credential store, a target and two different types of roles, right? So this is going to be done by the boundary administrator. Now, I'm going to use boundary UI in order to connect to the HashiTalks organization using user one. If you remember, user one was my CloudOps admin. So if I log in using the user one user, I'll see that if he goes to the SecOps project, he doesn't have any kind of an access, but in the CloudOps, he has access to both targets and the credential stores. So if I go to the credential stores, let's create a quick credential over here. I'll call this credential as CloudOne. I'll choose the type as username and password. We have other types as well. I'll keep the username as CloudOne and I'll give some random password over here and save this credential. Next, what I'm going to do is I'm going to go to the targets, which is created by boundary in the brokered credentials. I'm going to add this particular credential, which was just created. Okay, so now the credential is mapped. Now, what I'm going to use is I'm going to log into boundary desktop application using user two. User two was my CloudOps user. He's a password user, right? So I'm going to sign in to boundary desktop app. You will notice that he has a target called as CloudOps, but he doesn't have access to SecOps target. So now if I click on connect, I'll see the credentials for CloudOne. Okay. So yeah, that's it from the demo perspective. Now, so we are almost at the end of our talk and let's conclude our talk with a question. Does boundary replace Haship or Vault? The answer is no. Boundary is not intended to replace an existing secrets management solution. Boundary is designed to work with your secrets management solution like Haship or Vault to comprehensively secure infrastructure access. For customers who may not have a credential management solution or they are looking to easily onboard, boundary can function as a rudimentary static credential store. So if your organization's vision is to move towards zero trust security, then definitely Haship or Vault as a credential store is the way to go. That sums up my talk for today. You can reach me out on LinkedIn at slashin slash jameeth hyphen sami. Thank you very much for joining.
