Secure Access Management with HashiCorp Boundary

Boundary and Vault are two sides of the same coin. Vault secures access to infrastructure resources by tightly controlling access to target credentials based on client identity. Boundary takes that value prop a step further by securely monitoring and managing the user sessions that those credentials are used to create.

In this talk, you'll learn about the customer problems that Boundary will solve both long-term and in the current open source 0.1 release. You'll see a real demo of what it's like to manage and create sessions with Boundary so that you can see how easy it is to manage and monitor access at scale. And you'll see where the creators think the project goes from here and how you can try it out and get involved.

Transcript

Pete Pacent: Welcome to HashiConf Digital 2020. For anyone that was wondering, it turns out that redacted is not actually the name of the session. We didn't want to ruin the surprise of Boundary’s announcement — and Armon’s and Mitchell's keynote this morning, so we redacted the title.

For anyone that missed today's keynote, Boundary is a new secure access management offering from HashiCorp, that's going to enable identity-based access controls for dynamic infrastructure.

Today, Jeff Mitchell and I are going to give some context into the customer problems that Boundary will solve both long-term and for today's open source 0.1 release. We'll also run through a real demo of what it's like to manage and create sessions with Boundary so that you can see how easy it is to manage and monitor access at scale. Lastly, we'd love to share with you where we think the project goes from here and how you can try it out and get involved.

Let me introduce myself quickly. My name is Pete Pacent, and I'm the product management lead for Boundary. Joined with me today is Jeff Mitchell who's the principal engineer of secure products at HashiCorp.

Jeff Mitchell: Hi there. Yep. I'm a principal engineer in secure at HashiCorp. I've spent many years working on Vault, and more recently, I've been bootstrapping Boundary.

Pete Pacent: Awesome. Let's talk a little bit about Boundary's origin.

Multi-Cloud Security in a “Zero Trust” World

As we're all aware, HashiCorp builds automation tools for the various workflows in the application delivery lifecycle. One of the workflows in that delivery lifecycle is that ultimately humans — whether developers or DevOps engineers — are going to need to access their apps’ infrastructure. When they do, organizations need to ensure that access is securely monitored and managed.

I know what you're thinking: Wait, Pete, this sounds a lot like the Vault pitch — and it does because Boundary and Vault are two sides of the same coin. Vault secures access to infrastructure resources by tightly controlling access to target credentials based on client identity. Boundary takes that value prop a step further by securely monitoring and managing the user sessions that those credentials are used to create.

Traditional Workflow for Access

To better understand this, let's quickly revisit the scenario that Armon talked about in today's keynote. Let's consider a typical developer trying to access a production app or to troubleshoot an issue.

In a traditional access model, the app is likely deployed to a private network or VPC on a well-known set of virtual IP addresses and access securities configured at the IP level. This assumes a world where resource addresses don't change frequently.

In fact, they better not in this model because to configure any access to the target, I need to go through about 4 or 5 different steps. As a developer, I need to get access to a corporate VPN and then an SSH bastion host or privileged access management tool that straddles the corporate network and data center network. Like traffic is typically passed through some firewall that's enforcing IP-based policies on what access to this private network and app. On top of this, I may need credentials for each step plus credentials for the target itself — and those are often exposed to the end user.

Each one of these steps requires people and time to staff appropriately. And the attack surface areas for breaches in this model are also massive because — among many things — the potential time window for exploits can be long because of the overhead of updating each one of these controls independently. Despite all of these hurdles with a lot of overheads, I might be able to manage my app’s access in this model if it's deployed in a static environment on a well-known address space.

Dynamic Workflow for Access

What if I'm not running my app on that well-known set of addresses? What if I'm a developer at a modern digital company with apps and infrastructure across all of the major cloud platforms — as well as my own on-premises data center? What if I need to scale my infrastructure up and down to meet my application's availability and performance needs? What if infrastructure is continuously deployed, so the app’s resource instances and their network addresses are constantly changing? And what if I want to secure my apps and organization by creating a totally ephemeral access model for connecting to my infrastructure?

So the infrastructure itself is provisioned just-in-time — as are the credentials used to access the target and the session permissions use to connect. That traditional access workflow we just described requires a lot of manual configuration and overhead when I'm running on a single static app. And it becomes completely unmanageable when I'm dealing with ephemeral access at a modern cloud-scale.

Now, this model of ephemeral access is the problem Boundary is designed to solve. With Boundary, access permissions are based on the user client's identity rather than their network location or their access to static credentials. Their identity is assigned to a role which gives it access to a set of hosts and services that it can connect to and perform actions on securely — even over lower zero trust networks.

When I go to connect, the connection configuration to that end target is automated. When I say that, I mean the process of discovering new targets as they're deployed is automated — as is the process of applying my rules, policies, and credentials that govern how I can access my target. This way, the access policies assigned to that target are applied even as new host instances are provisioned or updated.

The Vision for HashiCorp Boundary

Our vision for Boundary open source is to enable this ephemeral model of access in which users can authenticate to Boundary — using their identity of choice — then are authorized to perform actions on dynamics sets of targets. Then be granted just-in-time access to connect to those targets via credentials provided by Vault or credential management solution of choice.

With Boundary's open source offering, we hope to lean into collaborating with partners in the community to build an ecosystem of integrations at each of the touchpoints in this workflow. Whether that's the identity provider you use to authenticate to Boundary, the cloud platform for which we support dynamic host discovery, or the credentials you used to access your target.

Boundary OSS 0.1.0

In today's 0.1 open source launch, we're going to focus on three main use cases within secure access management.

Granular Access Controls

The first is identity-based access controls for TCP based sessions. With this, administrators can define a perimeter of resources and identities under management. They can then create rules with granular permissions — in terms of what targets their users can access so that you can secure those targets over low or [zero trust] networks.

Automate Access

For end users accessing Boundary resources, you can connect through to your end target with whatever Layer 7 protocol you'd want to use to access your resources — whether that's SSH or RDP, Postgres, what have you. Administrators can then automate these access configurations and the discovery of hosts and services as they're provisioned with the use of a Boundary Terraform provider.

With this Terraform provider, you can configure your infrastructure's access policies with the same tool that you use to provision it. Outside of Terraform, API first design is a core principle of Boundary, and we’ll support configuration through a fully instrumented CLI, REST API, and SDK interfaces.

Session Visibility

Finally, admins can get the visibility into sessions created with Boundary through session logs that are exposed both through Boundary's administrative UI, or via integration with your log analytics or data visualization tool of choice. These session logs also answer questions like what identity accessed what system, when that access occurred, and when it might've been terminated.

Boundary’s Access Model

In terms of how Boundary actually creates and manages these sessions for users, Boundary clusters consist of a control plane and a set of worker nodes. Users connect to Boundary via a set of controllers that serve that actual control plane. The control plane manages what the user has access to and brokers that user session to a worker node — which then proxies the user session to the target system.

Currently, these workers serve as a transparent proxy. But in the future, Boundary workers will support protocol decoding to support things like managing an introspecting session activity.

One primary benefit of this model is that by managing access through these worker nodes, we avoid the need for an on-target agent, so you don't need to manage the resource constraints and complexity of adding yet another agent to your infrastructure.

Boundary Walkthrough Demo

With that, I'm going to hand it over to Jeff for a demo of Boundary's UI and command-line. He'll show you what it's like to create and manage sessions with Boundary. Then he'll show you how you can configure access at scale with Boundary's Terraform provider. Lastly, I'll show you how monitors can actually monitor and manage those sessions created through Boundary.

Jeff Mitchell: So I'm going to show a demo of Boundary here and show a bunch of different things. I'm going to deep dive in real fast, so bear with me. First, I'm going to launch boundary dev — like our other tools it uses dev mode.

Right now, it's creating a Postgres container. I'm going to copy that port for use later on. It's creating a number of resources within the system. These have a predictable suffix to make it easy to use existing scripts from one instantiation of dev mode to another — but you can change that if you want.

Authenticating Boundary

Next, I'm going to authenticate to Boundary so that I can make calls against it. After I authenticate, the token that's created will get stored in the system key chain so it's not stored on disk — it can also be provided through an NVR or a flag.

The super easy mode of getting started is that part of the resources we create in dev mode actually create a connection that's suitable for you to connect to your local box on SSH through Boundary. That's what I'm going to do now. And I'll explain more about what the targets are in a couple of moments.

You can see I'm now connected. And if you saw the text on the right scroll up, that's because I'm connected through Boundary. I mean that session through there. We can see that an authorized connection was established, it's closed.

I'm going to connect again so I can show you what this looks like in the UI. I'm going to go into this generated org scope. Scopes are resources containing other types of resources, and organization is essentially are there to hold infrastructure — things like auth methods and users and projects have infrastructure.

Cancelling a Boundary Session

I'm going to go into the sessions — and we can see that there's one session there that was terminated. That was the initial session I made. And there's another that's active. I'm going to hit cancel. We see that that session was closed because it was going through Boundary, and we decided that — you know what — I don't want to allow that session to keep going.

There are other things that will trigger that to happen automatically. For instance, if you de-authorize a user, if you remove their account from the system, it closes all sessions that are active. We try to make it very easy to say I don't want someone to have this session anymore, I want it to go away.

Boundary Target

I'm going to show you this target. There's a target that maps between connection information and host sets. Host sets contain one or more hosts that act as equivalent resources for the purposes of connecting. Then we can see in the target, a name — and so on. And a maximum duration, a maximum number of connections per authorized session, and a default port — which in this case is 20.

I'm going to make a new target. But first, I want to show one of the things related to this existing command, which we call styles.— We realized that people have different ideas of their preferred client for how they want to connect to any given application. I might want to use SSH command line. Other people might want to use PuTTy. By having these styles, we can invoke things that are not a single default.

By using something like that username flag. I'm connecting it through PuTTy here, but that username flag will mean that we're going to pass that username in the correct way, regardless of which client you're using.

Boundary Connect

Boundary connect there — it's a really powerful command. If I run boundary connect and give it a target ID, let's see what happens. When I run boundary connect, it's opening up a listening port on an interface — and that interface is controllable.

The port if you want, you can hard code it to something. Ideally, you won't do that because it's more secure not to. But that is opening this listening socket through which you can make an authenticated session. When we ran boundary connect — it went to the controller and said can I please make this session — can you please authorize me? And when the controller said yes, then it gave back the authorization information necessary for the client to make that connection.

This is really flexible. We can do this exec command for connect, and this is going to be the same thing as me doing boundary connect ssh, but boundary connect SSH, just a special case of running this exec command. If you do exec then anything that you pass after those double dashes will get sent to the command that's being exec-ed. And we can template in some things. You can see I'm using a login name of Jeff and a port of boundary.port. That didn't work because it's not boundary.host, its bounday.ip. I apologize for that. There's boundary.ip and boundary.outer, which has both.

You can see here, I'm connected in through Boundary again. But it said do you want to connect to this about the can't verify the host’s authenticity. When you use boundary connect ssh we can set a host key alias to make it transparent so you don't need to have that every single time you connect — have it be a new host that you have to authorize. Having those subcommands for boundary connect lets us make your life easy in terms of making those connections.

I'm going to go back to the UI. I'm going to make a new target for Postgres. I'm going to set the maximum duration to 15 seconds. I going to use -1. Postgres needs more than one connection to authenticate so I'm going to set it to -1, which is unlimited. I used the port that I copied at the very beginning of the demo from the container that was set up by boundary dev.

I need to add the host set — which has the localhost as a part of it — to the target. I copied the target ID. I'm going to run boundary connect postgres, give it that target ID, give it a username — again same thing — there are different styles we support and we can pass on the username where it makes sense. Now I'm connected to Postgres, and you can see I can do a described table and I can see the tables that are there.

We're going to see — if you remember — I set that session maximum lifetime to 15 seconds. If you look on the right in a couple of seconds, we'll see it — there it goes. It's closed, and now I can't connect anymore.

Attempting to reconnect will fail because that session is done. I can no longer make connections through that session anymore. I would have to reauthorize, go back to the controller, and ask for permission again to make more connections through that target; through that combination of time-based and connection count-based — it is powerful.

Boundary and Terraform

So now I'm going to show some of the Terraform language (HCL). Everything within Boundary can be described through Terraform — all the resources. This has an auth method and an account and a user for Pete.

Pete's not going to use it for what he's going to show you, but this is to show some of the completeness in terms of the UI and Terraform. There are some roles, some hosts, some hosts sets, and some targets. I'm going to apply this. Then we'll take a look at it within the UI to see what that looks like.

So you can probably imagine if you're already using Terraform to describe all of your infrastructure — all of your state — it's easy to get all of that into Boundary in a way that makes sense.

Org Scope

Now I'm in the org scope. I created this auth method that you can see. There was one account called Pete. I created a user for Pete Pacent — one account that's linked to that account ID. And I set up a role, which has just Pete — just that user as its lone principal — and a single grant, which is very tightly scoped. So it's for that initial generated target, it gives read and authorize session permissions.

Boundary is zero trust — it's default deny. There's no deny capability — you can only add. You start out with the ability to do nothing, and you have to explicitly grant what you want access to. But it also means that going in and generating this white swath and hoping that you've then locked down enough permissions is something that you don't need to worry about.

Generating Hosts

Then in this host catalog, we've now generated some hosts. We see Google and syriup — named for the way that my then three-year-old daughter would pronounce maple syrup. This host has www.google.com, and we're going to see what that looks like in a bit.

I created two host sets to hold those. And along with that, I created two targets. One is called RDP, and we can see I set the maximum connections. I think RDP takes two, but I was being lazy, and I set it to -1. You would probably not want to do that in a real production environment. And a default port of 3389, which is the RDP default port. I created one other target, which is HTTP to Googs, and a default port of 443.

So I'm going to show what these look like. I'm going to do boundary connect rdp. You can probably imagine what's going to happen. Give it our target ID, and it's launching the remote desktop client. That's my laptop — I'm now RDP'd into my laptop through Boundary

Next, I'm going to run a boundary connect http call. Got to go copy that target ID — and this is going to fail. That’s because when I connect to localhosts, in the absence of anything else, it'll look for a certificate that has an IP SAN — a social alternative name — of 127001.

One of those nice things that we can do for you is if you use these subcommands — if you tap in host and you give it the host to expect — we'll pop that host into the SNI header for TLS. You can see that when we do that, we're able to successfully fetch Google's homepage through Boundary.

You can do all sorts of fun with this. You can have authenticated calls to make DNS connections through dig to public servers if you want to. It's a pretty flexible system — especially using boundary connect with exec and building up your own set of commands.

Everything that you've seen in the UI and Terraform — we have a very full-featured CLI, it supports auto-completion everywhere. It supports flags for every single value, so every flag can be auto-completed. And you can see there I did a targets list and a target read on a particular ID. Everything that you see there is fully instrumented throughout the CLI, Terraform, and the UI as well.

Hopefully, this has been a good introduction to what Boundary can do, and I'm going to pass it back to Pete to show you some of the intelligence around it.

Pete Pacent: Thanks very much, Jeff.

Using Boundary to Gain Visibility into End User Sessions

Next, I'd like to quickly show you how Boundary gives you visibility into the sessions that end users create. I'm also locally hosting a Boundary cluster, but this time there are many users on our team that have used this cluster to access targets and create sessions.

While I can view a log of access data from those created sessions in Boundary's administrator UI, the Boundary cluster itself maintains a Postgres database that can serve this data so you can analyze it as you see fit — and even integrate it with your BI or security information event tool of choice.

Here I've created an example dashboard in Power BI that shows how easy it is to customize this data to fit your needs. In this dashboard, I can view the number of targets and users managed by this Boundary cluster, as well as the total number of sessions that have been created and the number of currently active sessions.

I can also see that one of my targets — in this case, my target for my application's Postgres instances — has a high number of active sessions. When I drill in, I can also see that one of my users — in this case Pete — has created an abnormally high number of sessions and that these sessions are all created in a short time span.

In the real world, this very well might indicate a potential security threat, in which case I can use Boundary's ability to revoke my role membership for that suspicious user or even terminate those sessions in real-time as Jeff demonstrated.

This is really one example of how to customize this data with Boundary. Given Boundary's open design, we're really just scratching the surface of your ability to define custom workflows for threat monitoring and management with Boundary.

Boundary at Launch and Next Steps

Hopefully, this demo gives a little more context in terms of how Boundary will enable granular identity-based access controls, access automation, and session monitoring. But to close, I'd like to talk a little bit more about where Boundary goes from here.

In our releases following launch, we'll be focused on building out the pillars of Boundary's ephemeral model of access. First, by focusing on enabling users to integrate their organization's identity provider of choice with Boundary — so Boundary's identity-based controls reflect the same identities that users have for their other applications.

Additionally, we'll focus on integration with Vault — or your preferred credential management solution of choice — so you can use ephemeral credentials minted by Vault to authenticate to Boundary targets. This would enable a single sign-on flow, so those creds are obscured from the actual end users of Boundary.

And lastly, we'll further streamline this access model by enabling administrators to define dynamic catalogs of hosts — even outside of Terraform — so services can be discovered based on predefined rules or tags on their environment of choice.

Try Boundary

We'd love to invite you to try out Boundary for yourselves. Boundary is now available to try out at Boundaryproject.io. We've got a whole set of onboarding docs and tutorials to make it easier to onboard and deep dive into the concepts and content of what Boundary is about. With that, though — really appreciate you taking the time to learn a little bit more about Boundary and looking forward to working with you to build this product out going forward.