BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News HashiCorp Boundary: Remote Access Management Service Adds OIDC Support

HashiCorp Boundary: Remote Access Management Service Adds OIDC Support

This item in japanese

HashiCorp has announced the release of version 0.2 of Boundary, their open-source identity-based access management service designed for dynamic infrastructure. This release includes support for OIDC authentication methods. The Boundary Desktop application is now at version 1.0 for macOS.

Boundary provides an alternative to traditional VPN or jump box based approaches for providing a gateway into a secure environment such as a VPC. Boundary acts as the gateway into the secure environment and integrates with the existing IDP to allow for authentication via SSO. Once the user is authenticated, policies are used to provide role based authorization to services.

Boundary authentication and authorization workflow

Boundary authentication and authorization workflow (credit: HashiCorp)

 

This release includes support for OpenID Connect (OIDC) authentication methods. This permits delegating authentication to external identity providers (IDPs). This includes integrating with services such as Microsoft Azure Active Directory, Okta, Auth0, AWS IAM, and others. This release has configuration support for the CLI with future releases integrating into Boundary's Terraform provider and the administrator console.

Boundary Desktop provides a full user interface to view the catalog of services and applications that the user has available. Once a service is selected, the user can connect directly to it via the desktop application. Current active sessions can also be monitored within the interface. This release sees the macOS version of Boundary Desktop reach 1.0 with a Windows version coming in a future release.

Terraform can be used to configure Boundary and declare the policies for authorization. For example, a global scope with a nested organizations scope could be created as follows:

resource "boundary_scope" "global" { 
  global_scope = true
  scope_id     = "global"
}

resource "boundary_scope" "org" {
  name                     = "organization_one"
  description              = "Org Scope"
  scope_id                 = boundary_scope.global.id
  auto_create_admin_role   = true 
  auto_create_default_role = true
}

A scope is a permission boundary modeled as a container. The global scope is always the outermost scope and is singular. Organizations can be nested under the global scope, with projects nested under orgs. Roles contain the set of permissions granted to any principal assigned to the role. For example, this snippet defines a read-only role for users in the readonly group attached to the org scope defined above:

resource "boundary_role" "organization_readonly" {
  name          = "Read-only"
  description   = "Read-only role"
  principal_ids = [boundary_group.readonly.id]
  grant_strings = ["id=*;type=*;actions=read"]
  scope_id      = boundary_scope.org.id
}

Boundary makes use of controllers and workers within its architecture. Controllers provide the API into the system and are responsible for understanding configuration, authentication, and authorization. They are stateless and can be scaled as needed to support high availability needs. Workers are responsible for the session recording and proxying. It is now possible to target traffic to specific worker sets via tags. State is maintained within a key management service (KMS) and database. This state includes the identities and access policies. The KMS acts as Boundary's root-of-trust and in-transit encryption.

Boundary cluster architecture

Boundary cluster architecture (credit: HashiCorp)

 

As Manav Mital, CEO at Cyral, noted in his recent article on access management within cloud environments, tools like Boundary or the Teleport Unified Access Plane can be used within a zero trust architecture. A traditional VPN or jump box setup provides users with network access making it challenging to limit access to services running within that private network. Boundary can be used to grant access to only the permitted services and not the entire network.

Future releases will offer integration with Vault and other secret management tooling to allow for ephemeral session credentials. While the initial release of Boundary allows for provisioning targets and access policies dynamically, it is planned to allow for defining of dynamic host catalogs based on predefined tags. This feature will support integrating with Consul, Kubernetes, and the major cloud providers.

Boundary can be deployed within a number of environments including Kubernetes, AWS, Azure, GCP, and Docker. Boundary is open-source and available on GitHub.

Rate this Article

Adoption
Style

BT