This week, HashiCorp hosted their second fully virtual conference, HashiConf Digital 2020. Although remote, HashiCorp has found a way to make digital conferences extremely engaging and have you feeling like you are there in person. Leading up to the conference, we were teased with not one, but two, new product announcements, Boundary and Waypoint. I plan to discuss Waypoint in a future article, but here I want to talk specifically about Boundary and what it is.
What is HashiCorp Boundary?
Leading up to the conference, HashiCorp did a great job at teasing the product announcements and not giving any major hints as to what they actually were. Being a HashiCorp Ambassador, I was lucky enough to get a sneak peek at Boundary a few days before the announcement. After seeing a demo and understanding the problems the tool is trying to solve, I was hooked. Boundary was built to modernize how clients access systems over a network by providing a single platform for them to authenticate to through some trusted IdP. Boundary then uses policies and RBAC to define what services authenticated clients can access on a particular network based on their identity. The following diagram from HashiCorp illustrating the Boundary workflow should help paint the picture further.
So what problem is Boundary trying to solve here? It helps to think about the process of traditional on-boarding and getting clients access to the machines that they need access to in a private network. Typically, when a client needs to be on-boarded a few things need to get created. The first is a VPN profile that will get them onto the network. The second is a set of firewall rules that need to be put in place that allow the clients access to the approriate machines. A potential issue here is that firewall rules are likely based on static attributes, such as an IP address. As more and more clients need to be on-boarded, this can become a overwhelming to manage, and as we move to a more dynamic provisioning model where IPs can change at a whim, management can become a complete nightmare.
With Boundary, the idea is that clients authenticate with a trusted IdP and are only shown hosts that they are allowed to connect to, which has been explicity set by permissions within Boundary. The key here is that we are now able to delegate access based on a logical service instead of a potentially dynamic detail, such as an IP address. With that mentality, we can now say “developers are allowed to talk to development machines in my private network” and at the end of the day, development machines can come and go, but the policy in Boundary will stay valid.
Level Setting on Terminology
With a new tool, there are new terms that will be thrown around so it is helpful to first review some of the key terms here and level set on their definitions. I am only going to cover a few below but you can view them all here.
- Host: A host represents a single machine that has a network address accessible from Boundary
- Host Set: A host set represents a collection of similar hosts for the purpose of access control
- Host Catalogs: A host catalog represents a collection of hosts and host sets
- Target: A target represents a resource that a client can connect to through Boundary
I’ve found that the best way to learn a new tool is to get hands-on with it. While writing this, this was my first time hands-on with Boundary, so I am learning with you! I have already installed the Boudndary binary installed on my machine so if you don’t have it yet, you can download from it here. I am going to run this in dev mode since this is just to get a feel for the tool. I eventually want to work on building an actual Boundary cluster that will be persistent.
Note: As a prerequisite, Docker must be installed on the machine you run Boundary dev mode on as well as have a
postgresqldocker image locally. You will also need to be able to SSH into your own local machine.
First step is to start up the Boundary client in dev mode.
$ boundary dev ... ==> Boundary server started! Log data will stream in below: ... [INFO] controller: cluster address: addr=127.0.0.1:9201 ... [INFO] worker: connected to controller: address=127.0.0.1:9201 ... [INFO] controller: worker successfully authed: name=dev-worker
Open a new terminal window, authenticate to Boundary.
$ boundary authenticate password -login-name=admin \ -password password -auth-method-id=ampw_1234567890
Once authenticated, you can list all known targets in the default project
$ boundary targets list -scope-id p_1234567890 Target information: ID: ttcp_1234567890 Version: 1 Type: tcp Name: Generated target Description: Provides an initial target in Boundary
By default, you will see one initial target that maps to your local machine. You can utilize Boundary’s
readargument to view full details about a Target as shown below.
$ boundary targets read -id ttcp_1234567890 ... Scope: ID: p_1234567890 Name: Generated project scope Parent Scope ID: o_1234567890 Type: project Host Sets: Host Catalog ID: hcst_1234567890 ID: hsst_1234567890 Attributes: Default Port: 22
By default, Boundary will try and authenticate via SSH over port 22. Let’s now utilize Boundary to SSH into our local machine. You will be prompted for your computer’s password to SSH into it.
$ boundary connect ssh -target-id ttcp_1234567890 Password:
Once you have authenticated, you have successfully connected into a machine through Boundary! To further explore a feature of Boundary, you can see the active session(s) in the UI. In a browser, navigate to
http://127.0.0.1:9200 and authenticate with the same username and password above. To view active sessions, click on the
Generated org scope box, then click on the
Generated project scope. You will now see a few new links on the side, specifically - Sessions, Targets, Host Catalogs. Right now, click on Sessions and you will see all active connections through Boundary. Specifically, you will see your active SSH connection to the local target as shown below.
Boundary also allows you to terminate connections from the UI. Click on the
Cancel button under the Actions column. If you go back to your terminal, you should now see the closed connection as shown below.
$ Connection to 127.0.0.1 closed by remote host. Connection to 127.0.0.1 closed.
So what have we done here? We have leveraged Boundary to SSH into our first machine, or in Boundary’s terms, our first target. I will add that this is a trivial example–in that you likely won’t setup your
localhost as a Target after this blog–but the concepts do apply to when you begin to add remote Targets, such as Google Compute Instances. As I begin to use Boundary further, I will write a follow-up blog where I deploy a Boundary cluster and add some real Targets, and show a potential workflow.
Being a 0.1.0 release, I am sure a lot will change over the next little while and I’m excited to see everything unfold! I know there will be a lot of integration coming with other HashiCorp tools, namely Consul and Vault, which I am super excited to see. If you have any additional questions about Boundary, please reach out! I am right here learning this tool with you so I’d love to hear your ideas and what you have been initially doing with Boundary.