Keynote - HashiCorp Boundary

Transcript

The next piece of this is: We have asserted a user identity, but how do we now interact with the machines, the applications, the services we want — that maybe understand those identities, or maybe don't understand those identities.

Traditional Workflow for System Access

When we talk about the traditional workflow for accessing these systems, it starts when a user probably requests access to some private resource. This could be — let's say — an internal database that's running on our private network. Maybe they're a database administrator — they need access to that database to perform routine operations.

They have probably provided a set of credentials that allow them to get on to the private network to begin with. This could be VPN credentials, could be SSH keys, etc. Then they need to know the hostnames and IP addresses of the database so that once they're on the network, they know what to connect to. And lastly, they need a set of application-specific credentials. In this case — database username and password — to be able to interact with the endpoint system.

Then their workflow goes left to right. First, they have to log in to the VPN server or the SSH server using those credentials that they have. Next, they need to request access over the network to that private system using the hostname or IPs they know about. Then once they're connected to the database, they would provide the application-specific credential — in this case — the database username and password. Then they'd be connected, and they can interact and perform whatever operations they need.

Now, there's a number of challenges with a traditional approach. This ties back to Mitchell's earlier point around this transition we're going through from static-based systems to more dynamic environments.

Onboarding Is Difficult

How do we think about onboarding new users? For every new user, do we need to distribute a set of new SSH keys, VPN credentials, database credentials, etc.? What about when that user leaves? What about having to do periodic password rotation or credential rotation? You can start to see how this onboarding process becomes cumbersome at scale.

 User Has Network Access

Next, the user is connecting directly to a VPN or directly to an SSH Bastion Host. That — in effect — brings the user on to our private network. While that has its advantage and that the user can now connect to these resources that are on the private network, it also has a disadvantage. The user can connect to all sorts of things that are on our private network. We don't necessarily want the user directly on the private network.

IPs Are Brittle

As a result, because the user should really only have access to a handful of systems, we typically would deploy a firewall in between the VPN and the target systems — or in between the SSH Bastion and the target systems. But that firewall operates at an IP level. There's a set of IP controls that constrain which set of users or which set of IPs have access to which set of IPs.

The challenge with this IP-based approach is that it's brittle. It works great in a very static environment. But the moment we have endpoints that are auto-scaling up and down, we're deploying new services, maybe we're running on Kubernetes where — if a node dies — the application gets moved to a different node and a different IP address. In these very dynamic environments, we have the challenge of keeping these IP rules — these IP controls — up to date. It becomes very brittle as our environment gets more and more dynamic.

Credentials Exposed

The last piece of this is the user has to have those endpoint credentials — the database username and password in this case — to connect to the target machine. This means we're disclosing it to the user. That user could potentially leak it, leave it on a passwords.txt on their desktop, post it into Slack, etc., — so we create an additional risk of those credentials to get exposed.

Dynamic Workflow for Access

A different way of thinking about this is to use identity as the core primitive. This would start where the user again logs in with their trusted form of identity. They don't use a specific set of VPN credentials or SSH keys that were distributed to them. Rather, they use their same single sign-on and use that one point of identity that they already have that the users onboard when they start.

Next, ideally, we would select the system we want to connect to from a set of existing hosts or services in a catalog. We wouldn't want to know a set of DNS names or hostnames or IP addresses that may or may not change in advance. We'd rather look at a dynamic catalog that shows us what we have access to.

The next piece is we want the controls of what we have access to, to not be at that IP level where it's a dynamic — but rather at a logical level, where it's service-to-service. I want my database administrators to have access to my set of databases, regardless of what the IP of those databases is.

Lastly, we want the connection to happen automatically to the endpoint service without necessarily giving the user the credentials underneath the hood. This has a number of advantages — if we can do this.

Onboarding is Easy

One is that onboarding and offboarding is dramatically simplified. We don't need to distribute a bunch of specific credentials. We don't need a rotation workflow. We don't need to offboard that user. We add them to our IDP or identity provider, and then we remove them from our identity provider. And everything is linked to that.

Network Remains Private

Next, because we're selecting a host from the service catalog, we don't need to give users direct access to the network. They don't need to know what the internal IP address is. They don't need to be on that private network because they just care about the target host — the target service that they're trying to access.

Configuration Is Stable

The advantage of moving the rules up from an IP level to a logical service space level is it's much less brittle. Now, we can put those services in an autoscaling group — scale them up and down. We can have them on a node, do a failover, and move the app to a different node. We can deploy net new services. And we don't have to worry about changing our controls all the time to keep pace.

Credentials Not Exposed

Lastly — because we're not distributing the credentials to the user themselves — they don't necessarily have the database username and password. When they connect automatically, they're authenticated against the database, and they've never seen the database credential — making it that much harder to expose it or cause an additional data leak.

Announcing HashiCorp Boundary

How do we make this workflow real? How do we move towards this identity-based model, rather than the more static traditional workflow? Today, I'm very excited to announce a brand-new project called HashiCorp Boundary. It's free, it's open source — and I want to spend a little bit of time today diving into what it is and how it works.

At the very highest level, Boundary is trying to provide the workflow that we talked about focused on that identity-centric workflow for how do we authenticate and authorize access to systems. This starts — as you would guess — with a user trying to access an endpoint system.

First, that user is going to authenticate themselves through one of these trusted forms of identity. Boundary makes this a highly pluggable thing. Whether that identity is being provided by Okta, by Ping, by ADFS, by Active Directory, it doesn't matter —  there's a pluggable provider, much like Vault that allows that identity to be bridged in from whatever existing IDP you have.

Once the user is in, we have a logical-based set of authorizations in terms of what that user can access. We might map that user into the group of database administrators. We'll say database administrators have access to a set of databases.

The notion of what a set of databases is, is dynamically maintained in a catalog. That catalog can be programmatically updated using a Terraform provider. It could be kept in sync by integration with Consul — where we're querying Consul’s view and service registry of what services are where. But it can also be integrated into other service catalogs such as Kubernetes, or AWS, or Cloud APIs.

These other systems have a notion of these services and the ability to tag them or add different selectors. Being able to import those and reference those in a dynamic way — rather than have to deal with static IPs — makes this much simpler to manage.

Lastly, when the user goes to connect, we don't want to provide the credential where we can until we can integrate with a system like Vault to provide the credential dynamically just in time.

In certain cases, we have no choice — we might have to provide the user with a static credential. But in cases where we can use Vault's dynamic secret capability, how do we generate a credential unique to that session that's short-lived and time-bounded? So the user can connect to the database with a unique credential for that session that they never even see? And at the end of their session, that credential can be revoked and cleaned up and isn't a long live static credential that we have to think about and manage?

The Goals for Boundary

The goals of Boundary are fourfold.

On-Demand Access

One is how do we do this on-demand access that's simple and secure. We don't want you to have to do a whole lot of pre-configuration and pre-setup. We want it to be very much push-button and on-demand.

Dynamic Environments

Two is we acknowledge the world is becoming much more dynamic, much more ephemeral. How do we support that? That's around a few of these different pieces. Making the system very API-driven and programmatic — integration with dynamic service catalogs, integration with dynamic secrets, and leaning into this notion that we don't want to manage static IPs because our world doesn't consist of static IPs.

Easy to Use

The other piece is making the system easy to use. We want it to be user friendly because you have administrators who are configuring it and maybe understand the system in depth — we have end users who don't care how it works. They just want to have access to these endpoint systems. And we want it as easy to use as possible.

Free and Open Source

We've seen time and time again with HashiCorp is that the best way to make these products successful is to build thriving communities on top and around them. We're excited to do exactly that with Boundary as well.

A Deeper Dive into Boundary

Here's a screenshot where you can see Boundary's UI. You'll see four different boxes that describe logical services that we might want to connect to. You'll notice we're not talking about IPs. We're not talking about a low-level host. We want to connect to this bucket of high-level services and the environment they're running in. This ties back to the three aims. Identity-based access and control, nothing is IP driven, nothing is host driven.

Two is we want an automated access workflow. We want this to be API-driven, to integrate it into our scripting environments, CLIs, automation tools, CI/CD pipelines, etc. So it’s a rich API that allows all of this to be automated.

Then lastly, how do we have first-class session management visibility and auditability of what's taking place? If we have privileged users accessing sensitive systems, we want to have full visibility of when and where that took place — and have that type of insight whether for security or compliance reasons. Of course, we know this is designed for practitioners because we also have a dark mode UI that's visible here as well.

Boundary Connect

Here's a different example of interacting, which is what we expect the day-to-day to be like. If I'm a Boundary end user — I'm not an administrator — I'm just trying to SSH into a target machine, how can we make this dead simple?

Here's how simple it can be; it's a single command. It's boundary connect ssh and the target that we're trying to get to. You can see that we are dropped right into a shell — and that's the goal. Behind the scenes, there's a whole lot of machinery that's making this possible. Our SSH client — that's running locally — is talking to a local agent that's spun up as part of this command; as part of boundary connect. That agent is doing the authentication for us against the gateway for Boundary and then establishing a connection to the Boundary gateway.

The Boundary gateway is then authenticating and authorizing us — and then connecting back to the endpoint system. Now we have an end-to-end connection, going from our machine to the gateway to the target environment.

But to the degree possible, all of this is automated and invisible to the user. They can continue to use whatever local tools they're comfortable with. Use your local SSH tool, use psql — use whatever local tooling — and you're always talking to a local agent that's proxying all the traffic back; very similar to how SSH port forwarding would work.

We're very excited about Boundary. Today is the launch of the product, and the 0.1 is available. Please go check it out at boundaryproject.io. It’s also on our GitHub page.

If you find issues, give us that feedback and engage with us (in our community forum). We’re super excited, and there’s going to be more content on Boundary later in the day.

Keynote Summary and Conclusion

Taking a quick step back, there are these four pillars as we think about zero trust security.

1. How do we assign workload identity?
2. How do we authenticate and authorize those machine workloads? That's our focus with Vault (the first 2 pillars).
3. How do we take that identity and broker machine-to-machine access in a secure and automated way? Our big focus there is with Consul.
4. As we bring humans into the loop, how do they authenticate and connect to these systems as well? We're introducing Boundary to look at solving this problem.

Then there are a whole slew of great existing solutions in terms of: How to do single sign-on and bring human identity in a scalable way.

All of this is part of our broader goal as we think about the security umbrella — the security focus at HashiCorp — how we do security the right way in these modern environments. Our strong conviction is the zero trust approach and identity-driven approach — where we have explicit authentication and explicit authorization for everything — is the right way to do this moving forward.

HashiConf Security Deep-Dive Breakouts

As we shared earlier, the theme of today is talking about security. Right after this keynote, we have a great line-up of more security-related talks. If you're interested in Vault's future, we're going to have a deep dive on that. If you're curious to learn more about Boundary — our new tool — we're going to have a deep dive session specifically on going into Boundary. We'll talk about HCP Vault and what that looks like and how that works, as well as a few other great security-related talks. Stay tuned right after this for all of those talks as well.

Looking ahead to HashiConf Day Two

We already announced a whole bunch of new things today — including Boundary, HCP Vault, and Consul. But we’re not quite done yet. You may have seen some of our teasers on Twitter as well as on email, but we have one more big thing to share with you. Stay tuned for that update during tomorrow’s opening keynote as well.

The rest of the sessions — both today and tomorrow — we have a great lineup of speakers, a lot of great content. All of this is going to be available on-demand if you can't catch it all live — so don't worry and stress out about that. But at this point, I hope you all enjoyed the conference, and I'd like to hand it back over to our wonderful MCs.