How HashiCorp Boundary Brings Cloud Native Computing to the Developer Desktop – InApps 2022

HashiCorp’s open source remote access software Boundary, unveiled last week at the HashiConf, promises to provide an easy way for developers to hook into cloud native services, according to this presentation from HashiCorp co-founder and chief technology officer Armon Dadgar.

Cloud native is moving to a zero-trust approach to security, and so the remote access tools the developers use to build apps need to better accommodate this shift. With Boundary, “we move towards [an] identity-centric, policy-driven approach to security and get rid of users having direct access to credentials or direct access to the private network,” Dadgar said.

Traditionally, a developer working from home, or a contractor, who needs access to a database or some other internal resource would need to be given access to the organization’s private network. They may use a VPN, or ssh, and a firewall restricts unwanted the user from accessing other, potentially sensitive, areas. A username/password may also needed for the database itself.

This approach has some management headaches, Dadgar pointed out: ssh keys must be allocated and de-provisioned when no longer needed, dynamically allocated IP addresses must be kept track of, and end users must be trusted to protect their database log-ins. And, of course, handing out keys to a private network is, in general, a security hazard.

In HashiCorp’s new approach, the end-client is not bridged back into the private network. “They can not ask the gateway to initiate the connection,” Dadgar said. Instead, the user is authenticated locally by a trusted identity provider (IDP)  such as Active Directory. To govern access, the organization sets a system-wide policy profile, based on role-based access control, to determined what services the end-user specifically has access to. Database administrators get access to only the database, for instance. The resources are not defined by their IP numbers, which are always changing in a dynamic cloud native environment, but by tags that define the service, abstracting away the low-level configuration settings.  “The granularity that we will specify this policy at is not necessarily single host/single IP but logical services,” Dadgar said.

With this approach, VPN or SSH credentials do not need to be distributed. The user doesn’t even need the application credentials in most cases. For those apps that do require credentialing that are not recognized by Boundary, temporary credentials, or “secrets,” can be issued by HashiCorp Vault, to limit how long they will be out in the wild.

How does this look to the end user? They are given a command-line interface (CLI) in which the Boundary command kicks starts a local agent that will handle the authorization flow with the gateway, checking the permissions through the policy agent. The gateway establishes a connection directly to the target system. The user then types in the typical commands as normal, which are tunneled back to the app. Boundary also has a Web user interface, and will eventually offer a desktop app, offering a clickable catalog of available services.

Architecturally, Boundary has a set of controllers, which provide the APIs and manage the API calls. Controllers are stateless though they may interact with a key-value store to hold needed info and metadata. Another component, the workers, does the networking of connecting the client to the resource, communicating with the controllers to get the authentication credentials. Both the worker and the controller are scalable, though initially they both can be run initially as a single binary.

Behind the scenes, Boundary relies on HashiCorp’s open source Terraform infrastructure-as-code provisioning tool, which manages the policies and configurations (though given that the controllers are API-driven, other approaches can be used). The policies are not expressed at the IP level, but rather as logical services. Terraform operates on “dynamic host sets,” which provide the necessary metadata for operating with different dynamically-allocated services providers such as Amazon Web Services or Kubernetes.