HashiCorp Boundary — An open-source route to Cloud Security.
Within software engineering, and especially the vast (relatively) new world of cloud adoption, it’s acceptable to say that Security isn’t at the forefront of every developer or cloud consultant’s mind. Each team that plays a part in the process of Cloud Development has an objective in their field of view, with Security being sometimes left in the backseat of the Cloud adoption train. With Zero Trust Network Architecture (ZTNA) becoming more of a trending topic, and embraced as one of the main security design principles to adhere to, we need to identify and utilize technologies that provide a strong central policy engine and corresponding enforcements points, while at the same time providing the capability of being automated and considered into a larger process, workflow, and pipeline to allow for flexibility and scalability long term.
The Technical Challenge:
One of the main challenges that arises when working with Public Cloud, is how do we provide administrative access to resources (like back-end databases), while at the same time maintaining segregation between applications tiers without using a bastion host or VPN-based architecture. From a Cloud administrator’s point of view, it’s a tough act to balance securing access to resources, while ensuring that a Security Group, IAM or Resource-Based policy is not too permissive, juggling with not over-exposing our critical resources to the world wide web and giving out the right credentials and level of access to infrastructure administrators. In an ideal world, it would be great to have production systems where no one ever has direct access to any of the underlying systems or databases comprising a given service.
How can we keep to CNCF (Cloud Native Computing Foundation) guidelines and maintain those practices along the way? In reality, we end up having to adopt practices that fit our specific needs, tailoring them to work within our particular environment and use case to ultimately meet our business needs.
This can be somewhat of a challenge to overcome. Luckily, we can also look at the wider CNCF integration ecosystem, where there are some tools out there that can help ease some of the burden of this complexity.
The short version: Why HashiCorp Boundary for you?
1. I’m technical, what would Boundary do for me day-to-day?
- Boundary is entirely open source, and can provide a secure mechanism to access hosts and critical systems across multiple providers separately without the need of managing individual credentials for respective systems as it integrates with identity providers and removing the requirement of exposing your infrastructure to the public.
- Boundary focuses on scalability as a core part of the system design which applies to both organisational scaling through the use of multiple organizations, scopes, authentication methods and also RPS-style (Request per Second) scaling, while providing segmentation between organizational scopes and resource access, using cloud infrastructure to facilitate the necessary growth on demand.
- Easily integratable into workflows through API’s for rapidly changing and dynamic environments.
- Build a secure administration environment that works towards Zero Trust Network Architecture, as every administrative connection is monitored and authenticated.
- Boundary builds on experience with HashiCorp Vault in terms of security best practices.
2. I’m a C-Level or stakeholder, how will this help my business?
- Increased cost saving by reducing infrastructure required for administration.
- Greater business agility by ensuring access to core systems is dynamically and securely managed.
- Streamlined contractor and administrator access.
- Reduced security risk and surface exposure through technology ecosystem integration.
- Positive contribution towards regulation and Compliance through adherence to certain compliance standards.
The longer version, what is Boundary?
Boundary from HashiCorp is an offering designed to help solve these challenges, by bridging the policy permissiveness gap for administrative resources, providing the necessary balance between over-exposure and air-gapping for a given environment, while simultaneously providing the identity controls you would expect from an enterprise level solution.
Boundary is an open source project developed to control client-to-server access at a granular level. In short, it allows for users authenticated locally or against an identity provider (i.e. Google, Okta, Azure AD, etc.) to be authorized to access specific secure systems (identified within boundary) within private networks, without granting access to the systems directly, and without providing visibility of the larger network where those systems reside on — think of an Application Proxy — along with any other systems within the same network that certain administrators should not have access to. All this is provided through a central location, with the possibility of being configured with high-availability of course, and exposed through a Cloud Native load-balancer. Depending on configuration and implementation, Boundary can handle IAM access from a development to production infrastructure standpoint.
Boundary is definitely a tool to add to your security or development toolbox. It’s a component in the larger cloud security strategy with potential to solve further use cases going forward. Being an offering from HashiCorp, it naturally provides the capability of being easily integrated into workflows, meaning that it is easily deployable through Infrastructure as Code with Terraform into most Public Cloud Platforms. The necessary code is already on GitHub ready to be used. It’s also an API-driven system, providing a CLI, a Go SDK and a desktop app for ease of use.
Core Features and Benefits
- Identity-based Access
- Session Monitoring and Management
- Secure Access to Dynamic Environments
- Platform Agnostic
- HashiCorp Portfolio Integration
How does it work?
Access to Boundary and corresponding resources is based on the trusted identity of the user. The user connects to the Boundary gateway, which authenticates them against an identity provider which is configured within Boundary. Based on the users group attachment’s assigned roles and permissions, they can then connect to other available cloud resources, logically defined services, or hosts using the Boundary service as a gateway node to facilitate connectivity.
$ boundary connect ssh -target-id ttcp_1234567890
Boundary is designed to integrate with existing HashiCorp offerings, namely Consul (service mesh) for dynamic service discovery, Vault for secrets management (explained further below), and Terraform for deployment/integration with the given environment.
Why use Boundary over a traditional bastion host architecture?
By having Boundary as the interface connecting towards your backend infrastructure, it reduces the need for additional filtering mechanisms such as NVA’s to limit connectivity to the bastion host, and another layer of policing from the bastion host to the necessary infrastructure, that may have to be integrated with another role based access control mechanism.
What would this look like in my company?
In a typical cloud environment, we’d expect the organizational structure to look like the following:
How does it scale?
In the interest of improving operational workflows and leveraging automation when using Terraform in an AWS environment as an example, we can use EventBridge to schedule CodeBuild when there is an EC2 instance creation, tagging or deletion in order to re-apply Terraform when a new server is created or destroyed with a specific tag, for example #Boundary-Web-Frontend. This would allow servers that are created with that tag to be added to the Web-Frontend-Targets host set (group of servers), and be easily manageable by the existing administrators with minimal operational overhead.
How did we find it?
We proceeded to setup the non-dev HA environment in AWS recommended by the platform with the Terraform code provided:
Core design principles:
- Multi-AZ architecture
- ALB only is publicly exposed which provides access to the Controller nodes
- Health Monitor for key Controller TCP ports (9200)
- Fault-tolerant Controller and Worker Node setup
- Controller Nodes are responsible for Control Plane, Worker Nodes for Data Plane (can be run as a single entity if required).
- Auto-Scaling group to ensure redundancy and scalability.
The experience
The HashiCorp learning portal provides a solid footing towards getting started with Boundary.
Between setting up a test environment through an online provided sandbox, or downloading it locally and setting up a dev instance, it’s a quick 5 minute process to get up and running and familiarize yourself with the core principles of Boundary. The portal provides a simple step by step guide on managing users, roles, principles, sessions, connecting to targets, and also using the Boundary Desktop application in the dev instance. It concludes by providing the how-to on setting up the boundary application through Terraform.
The use of scopes -
$ boundary scopes create -scope-id=global -name=IT_Support -description=”IT Support Team”
-combined with the use of separate authentication methods, projects/users/groups/principles and roles, provides a simple and natural way of segregating resource and access controls and limiting privilege to specific targets:
$ boundary auth-methods create oidc \
-issuer “https://ISSUER_URL" \
-client-id CLIENT_ID \
-client-secret CLIENT_SECRET \
-signing-algorithm RS256 \
-api-url-prefix “http://localhost:9200" \
-name “auth0”
$ boundary groups create -name=”group01" -description=”A test group” -scope-id=$ORG_ID
$ boundary users create -name=”tester01" -description=”A test user” -scope-id=$ORG_ID
The ease of use from an API perspective allows for dynamic and rapidly changing environments to be integrated easily into Boundary and used with services such as Lambda, CodeBuild and Terraform to integrate into larger workflows.
As of version 0.4.0, from a wider ecosystem integration perspective, the integration with Vault also provides the capability to broker Vault secrets for Boundary sessions which from a security perspective is a valuable upgrade. The full setup information is provided here however the summary of those steps are:
- Firstly configuring a boundary controller policy in Vault which allows Vault to check, refresh, and revoke any tokens and leases as deemed required in order to properly manage and broker the credentials supplied.
- The creation of a database secrets engine and associated roles to generate credentials, along with the policy to allow access to the DB from those Roles.
- And then the creation of a Vault Token is required for accessing the Boundary credential store.
- Creation of a Boundary target for the database roles created.
- Finally, building the credential store (pointing towards Vault) and credentials libraries for each database role, and associating with each other.
As an open-source piece of software, the use of the product as an alternative to a privileged management solution is definitely a possibility. Integrating with OIDC and the use of MFA could easily be used as a method of elevating privileges when accessing core resources under a specific scope. However, the limitation of a simple way of viewing logging and auditing of the platform could be a deterrent for some administrators, as the auditing feature is still extremely new and according to the developers there are still some changes to come in the future. However if required, logs can be outputted as cloudevents in a json format.
Boundary Limitations
It is worth mentioning that Boundary is a fairly new project (0.5.0 release as of this evaluation), so there are still a few features that are not currently in Boundary, but the team are working towards making these available.
One of the core capabilities that we believe is functionally required and not currently available is having Boundary block access to a user after multiple failed attempts. Arguably, this could be enforced at the IDP/functional endpoint level. At the moment Boundary doesn’t have this feature, but it is on the roadmap.
Closing Thoughts
Boundary is a relatively new offering which can help bridge the gaps when it comes to user authentication, access and segmentation of systems within a given environment, and be implemented in a relatively short amount of time. If your cloud environment is in need of a way of implementing granular identity controls in an agile manner for purely the cost of the instances being run and the investment of your own time, this is the solution for you.
It’s absolutely worth keeping an eye on as it matures, as the potential benefits that it may bring to the table in the near future are bound to help an organization, especially when combined with other offerings from HashiCorp.
Given the open source aspect of the project, it’s ripe for contributions and substantial upgrades from the community over time which we look forward to seeing.
BA
