Shadow and Dust: Better Security Through HashiCorp Boundary and Ephemeral Infrastructure

HashiCorp Boundary is a new open source project that enables practitioners and operators to securely access dynamic hosts and services with fine-grained authorization without requiring direct network access. The 0.1 release of Boundary has been years in the making; the journey to build Boundary began in 2017 as an investigation into managing sessions established with credentials generated by HashiCorp Vault.

This investigation led our team to ask a number of fundamental questions about identity and access management. Throughout our investigation, one question seemed to dominate conversations: Why do systems need to exist before users and applications request access to them?

»What is Ephemeral Infrastructure?

If you wanted to summarize HashiCorp, you could describe our products as automation to facilitate the digital migration of the world. As individuals, teams, and organizations migrate to a digitally-aligned world, our products exist to allow those users to consistently provision, secure, connect, and run any kind of infrastructure for any kind of application.

HashiCorp’s products allow developers and operators to span workflows across infrastructure principles — storage, networking, and compute resources across clouds and on-prem infrastructure — thereby ensuring that as changes to that infrastructure occur due to economics or technological advancements that the workflows remain consistent.

We call this dynamic infrastructure: a style of IT and DevOps where you can change principles of how workflows are executed without disrupting the workflow itself. Want to adopt a new cloud? Just mount a new auth method or instantiate a new Terraform provider. Need to connect a new container application? Register a new service with Consul. Need to run all of this when I don’t necessarily know what resources are available across my global infrastructure? Hello, Nomad.

The rise of dynamic infrastructure is the consequence of a world digitizing its economies in the face of radical technological and social change. It represents a massive $1 trillion global effort to bring traditional IT and non-digitized infrastructure to a world that is driven by software developers writing applications across infrastructures: on-prem multiple clouds, various container environments, and increasingly serverless-style architectures.

When you trend this effort forward ten years we believe dynamic infrastructure no longer is a disruptive trend; it’s the norm. Instead, the next disruptive trend is a more aggressive form of dynamic infrastructure: ephemeral infrastructure.

In ephemeral infrastructure, the notion of a traditional infrastructure primitive or principal goes away. As an application developer operating within ephemeral infrastructure, I no longer think of how my application is networked or requests data from storage. In fact, I basically no longer think of my infrastructure at all. Instead, as a developer or operator I ask a more holistic question: “where would I like my code to run today to best accomplish my objectives?”

Automation in ephemeral infrastructure ensures that constructs like identity credentials or access rights are abstracted completely from where that code may execute (not to mention the developer writing that code). That code’s infrastructure is deployed just-in-time per the developer’s needs.

To preserve cost and ensure optimal use of resources, once that code’s operations or workflow is complete its infrastructure disappears; its resources are yielded back so that other code may similarly execute and run in a highly optimized fashion per their developers’ requirements.

Ephemeral infrastructure is extremely disruptive to traditional conventions of IT. But it also provides a quantum leap forward in security. With ephemeral infrastructure, the window for an adversary to monitor and prosecute an attack on a target is minimized. Such a minimized threat surface ensures that many of the APT-style of prolonged attack campaigns seen in data breaches during the 2010s are impossible.

With ephemeral infrastructure an adversary needs to prosecute a perfect attack, with perfect cover against detection, at the perfect time because the system they’re attacking may not exist in ten seconds.

»Boundary and Ephemeral Infrastructure

Boundary realizes the security benefits of ephemeral infrastructure in two key ways:

»Ephemeral Targets

In Boundary, a user or application requests access to a target — a privileged system that the user or app is expressly permitted to access. Boundary’s infrastructure is built such that the target doesn’t actually need to exist prior to an application requesting access to it.

An example of an SSH session established by Boundary to a target system executed dynamically by Nomad. This was the first architectural diagram created by the early Boundary team.

Controllers, the intelligence engines powering how Boundary interprets and launches session establishment workflows, can direct dynamically provisioned Workers to execute the creation of the target just in time. When paired with HashiCorp products like Terraform, Nomad, Consul, and Vault, this allows for a fully distributed and fully ephemeral infrastructure.

For example, a user may wish to SSH into a target system hosting a database. In response, Boundary and Terraform coordinate to apply a plan describing the components of that database system in real time. Nomad can be used to execute the creation of that database system from the components instantiated by Terraform. Consul can register the database system service in the infrastructure’s network, thereby permitting routing from the Boundary user to the end system. And Vault can create a dynamic credential for that database, ensuring that Boundary can create a secured and privilege-scoped session for the user to access that database.

All of this is opaque to the user. They only see themselves authenticating to Boundary and requesting that session. In essence, they insert a key into a door on an empty street. When they turn the handle, a house is built instantly around that door and filled with the plumbing, lighting, and furniture they need to enjoy their stay.

Just as easy as it is to deploy this infrastructure, Boundary is able to pair with the other products in the Hashi stack to quickly remove it and return the resources it consumes back to the computing pool.

When the user is done, they walk out of the house. The moment they step out, this system architecture can trigger a workflow to destroy the target, incinerating the house. Turning around the user finds the house gone — the only proof it existed kept in the logs of Boundary and the other tools used to provision and run the target.

This style of just in time provisioning of targets makes attacking a target very difficult for an adversary. An enterprising hacker looking to launch an attack on the user has to attempt to detect and compromise the user’s session. This is easier said than done, as there’s no mandate that the user has to begin a session at any particular or regular time.

Strong encryption via TLS ensures that the user’s session is resolved against eavesdropping, and attacking the target to steal the data of the application or user is further complicated by the fact that the target won’t exist after the user leaves their session.

Essentially an adversary attempting to break into a user’s “house” now needs to penetrate a castle surrounded by a nearly impenetrable wall of fire. Even if they get past that, they also need to breach a windowless inner keep in a matter of seconds as once the user is done with their session the castle will disappear.

In the words of the ancient philosopher Zuko, “that’s rough buddy.”

»Credential Abstraction

One key component of Boundary’s architecture is how it handles credentials. In Boundary, credentials for targets are held in Credential Libraries. A credential library can hold static secrets for permanent targets, or it can be directed to generate dynamic credentials for a target from a secrets management system like HashiCorp Vault.

It’s important to note though that Boundary does not require Vault to populate its credential set, and could utilize other secrets management suites like CyberArk Password Vault to resource static or dynamic credentials.

Applications and users attempting to establish a session through Boundary never have access to Credential Libraries. Boundary further protects these Credential Libraries, like Vault, with strong encryption built for secure long-term storage of this sensitive data. This ensures that static credentials protected by Boundary will stand up to hacking and codebreaking attempts from even well-resourced, expert adversaries.

The ability for Credential Libraries to utilize dynamic credentials further enhances this security, as it ensures that even if Boundary were to be breached through some currently non-existent form of cryptanalysis utilizing yet-unknown properties of Number Theory or Combinatorics that the session could be simply terminated and any stolen credentials rendered useless.

»Shadow and Dust

In his Odes, the Roman poet Horace famously underscores the ephemeral nature of life with the line:

Pulvis et Umbra Sumus. We are shadow and dust.

Ephemerality poses deep questions in philosophy. But in infrastructure security, ephemerality is critical to protecting sensitive information from advanced adversaries — today and in the future.

HashiCorp Boundary provides a pathway to significantly improving network security. With ephemeral targets and credential abstraction, an adversary attempting to compromise an ephemeral system protected by Boundary faces an incredible challenge:

There’s nothing to steal but shadow and dust.

To learn more about Boundary, please visit the project website at boundaryproject.io, github.com/hashicorp/boundary for the source code, and HashiCorp Learn to find our step-by-step tutorials to get started with Boundary.