In the ever-changing world of software development, striking the right balance between top-notch security and ease of access for developers is no walk in the park. Conventional wisdom and best practices dictate that we need to build towering walls around our digital fortresses, blocking any unnecessary access points to keep potential attackers at bay. While this approach is effective for security, it often creates a complex maze that our own developers have to navigate for routine tasks such as running scripts, viewing internal dashboards, connecting to databases, and so forth.
At Kapstan, I realized early on that existing solutions to this problem were either clunky to use, or left a lot of features to be desired. Bastion hosts and Virtual Private Networks (VPNs) would require me to distribute new credentials (SSH keys, TLS certificates) to every employee, and if I wanted to restrict access to certain resources it would require further layers of setup on top. I knew that any of the pain points our team experienced would be felt by similar fast paced & quickly growing engineering teams as well. I set out to find a modern solution that could uphold our core values of security and simplicity, while not compromising on features. We had been using other HashiCorp products like Vault and Terraform from the beginning and had run across one of their newer products: Boundary. It seemed to check every box, promising a high degree of security, multi-cloud flexibility, and simplicity by supporting OpenID Connect (OIDC) for authentication. As I dug deeper, I saw an active community on the HashiCorp boards, a frequently updated Terraform provider, and built in integration with Vault. I knew I had stumbled upon something worth experimenting with.
This post will take you through an introduction into the world of Boundary, how it has transformed our company’s approach to secure infrastructure and application access, and a simple demo to get you started with this tool. We’ll cover some of the difficulties I faced setting it up, and some suggestions for how to get the most out of it.
What is Boundary?
Let’s dive into what makes HashiCorp’s Boundary an essential tool for secure and simple access.
Key features of Boundary include:
Identity-Based Access: With Boundary, it’s all about who you are, not what keys you carry. It keeps things secure without making you jump through hoops by integrating with tools you’ve already set up, like Azure AD, Google Workspaces, or Okta to automatically provide customizable levels of access to your entire team.
Secure Connections: Every connection made through Boundary is encrypted, ensuring a secure passage for your data. Certificates and keys are generated on-demand and discarded once you disconnect, reducing the risk of interception.
Session Management: Administrators can monitor, manage, and terminate sessions, giving them full control over active connections. Boundary also supports a high level of configurability to automate rules (such as limiting the maximum duration a user could be connected to a database).
Role-Based Access Control (RBAC): With Boundary, you can define access permissions based on job functions by creating roles. This ensures that users only have access to what they need rather than full access to everything on your network. These roles can be dynamically evaluated every login based on attributes from your Identity Provider, such as a role within Azure AD, so that all user configuration lives in one portal.
Credential Brokering: Boundary can integrate with Vault and utilize its secret engines for dynamic credentials, such as database users, Kubernetes service accounts, and more. These credentials are removed after the session ends, so even if they are leaked, they’ll have been deleted long before anyone tries to use them.
Multi-Cloud/Hybrid Setup Support: Any place you can run a simple process and have internet connection can become part of your infrastructure open to Boundary. This means those eyeing multi-cloud or hybrid cloud and on-prem setups can centralize all developer access into one convenient portal.
The Good
At Kapstan, we’ve utilized Boundary to streamline our developer access to infrastructure. For us, setting up a new developer is as simple as creating a company email.
Remember the headaches of onboarding and offboarding team members? With Boundary those are long gone. For every new hire, I used to have to generate and distribute different credentials, and if any accidentally got leaked I would have to redo the whole process over. Now, I simply create their user in Azure AD and assign them one of a few roles. For those who only need simple access, I have made a “read-only” role that immediately gives them access “read-only” targets in Boundary, such as pod logs collected by Loki. This empowers them to independently debug issues rather than relying on others. This automatic access not only fast-tracks their onboarding but also fosters a more self-reliant team along the way.
For our team members who need more extensive access, I leverage Boundary’s credential store integration with Vault to automate the generation of database users with pre-defined permissions, eliminating the need for manual setup and cleanup. No more manual key management, simply sign in to Boundary with your company email, and it handles the rest.
As Kapstan grows, and our tech gets more complex (as tech does), Boundary’s right there with us, growing in stride. Everything is grouped into easy to manage ‘scopes’ and user permissions are evaluated on every log in. This means as we spin up any new infrastructure or deploy new applications, we just need to add it to right scope and intended users automatically get access to them without any additional configuration. Since everything in Boundary can be configured via Terraform, it becomes exceedingly simple to track changes in our configuration over time and empower all developers to contribute to adding new targets to connect to. Whenever our team deploys a new service with an admin panel, such as Argo, all it takes is a few lines of code to configure Boundary to provide secure access to the intended users.
The Bad
No solution is perfect, however, and using Boundary has posed some interesting challenges to overcome. Setting everything up from scratch? Expect to roll up your sleeves and embrace your inner DIY enthusiast. HashiCorp does provide a suggested reference architecture, as well as a community-supported repository of Terraform examples, but they often require some fine-tuning and you will likely need to do some documentation diving to achieve your desired setup. It does come with slightly higher infrastructure demands than the alternatives as well. You’ll want at least two separate compute instances (HashiCorp does offer an official image to simplify keeping everything within Kubernetes as well) and a database for storing your configuration and session information. It’s not rocket science, and I found ways to keep costs down, but be ready for a bit more tinkering compared to other options.
Since Boundary itself is still in development (version 0.13.1 as of writing this), there have been a couple of additional hiccups along the way. We’ve run into some minor glitches when using the Terraform provider, notably some trouble using AWS keys in subaccounts but loading credentials from environment variables resolved these. As with any early stage software, expect frequent bug fixes and feature upgrades as well as the additional maintenance requirements that come with them. Luckily, the Boundary CLI comes pre-packed with a database migration feature that can automatically update your database to meet the newest configurations when upgrading between versions.
The user experience with Boundary is fully capable, but it can be a bit rough around the edges. Since Boundary relies on a local process to connect, you won’t have the luxury of recognizable URLs for your resources. Though you can set preferred ports (such as proxying your Postgres connection to localhost:5432), don’t expect your web applications to be accessible at qualified URLs. Boundary offers both a CLI and a dedicated client. The CLI, bundled with multiple plugins to simplify connections to common target types (like databases), is easily my go-to method and works well. On the other hand, the dedicated client, while sporting a fairly nice UI, can present some confusing errors. In those cases, the time-honored tradition of turning it off and back on again usually does the trick.
Demo
I’ve prepared a simple demo to run on your local machine so that it’s easy to get a feel for Boundary’s work flow. It starts off with a simple target to connect to then shows some additional configuration you can do to get database credential management with vault.
Link
Closing Thoughts
I hope this dive into Boundary and how we use it at Kapstan has been useful. It’s been a real game-changer for us, making the tricky business of secure access a whole lot simpler.
At Kapstan we are passionately working on solving DevSecOps challenges for modern engineering teams. Kapstan makes infrastructure deployments fast, simple, and secure. If compliance is on the horizon, rest easy knowing that infrastructure deployed by Kapstan is SOC2 compliant out of the box.
We automatically setup security & observability tools (like Boundary) to integrate with your infrastructure and applications, so you get all of the benefits without any of the headache. Curious? Want to chat more about how we could work together? Feel free to drop us a line at hi@kapstan.io. We’re always here and ready to talk tech.
