Introduction
Why use HashiCorp Validated Designs?
HashiCorp Validated Designs (HVD) provide practitioners with opinionated guidance for achieving production-grade deployments of HashiCorp products. These designs are purpose-built for delivering foundational use cases, with a baseline level of architectural and operational maturity. They draw on the field experiences of Solutions Engineers and Solutions Architects working with customers across a wide range of environments and organizational requirements.
Each guide provides access to an opinionated reference architecture, including key design decisions and the rationale behind them. Where applicable, guides identify modular design components that you can adjust to align with organizational or regulatory requirements without compromising the overall integrity of the implementation. For many deployments we include Terraform modules to automate large portions of infrastructure provisioning and software installation.
This User Guide covers the use cases that Boundary Enterprise supports once the platform is installed and operational. Use it to configure and enable Boundary features for your consumer teams, from foundational access workflows through to advanced, scaling-phase capabilities.
References to Boundary in this document apply to both HCP Boundary and Boundary Enterprise except where specified to indicate differences between the products. We also use Boundary in the context of the command-line tool where applicable.
Prerequisites
This guide assumes that Boundary Enterprise has already been deployed and brought into service. Before using this guide, complete the following:
- Deploy Boundary Enterprise following the Boundary Installation Guide.
- Review the Boundary Administration Guide for the system-level operations that support these use cases.
The use cases in this guide are ordered roughly from foundational to advanced, but you can navigate to any use case directly using the section headings.
Language and definitions
While this guide intentionally uses technology-agnostic language, there are some terms that do not translate seamlessly between providers. This document uses the following terms:
| Term | Definition |
|---|---|
| Scope | A permission boundary modeled as a container for resources. |
| Global scope | The top-level scope that encompasses all child scopes within the boundary system. It serves as the root of the hierarchical structure to organize resources. The resources such as storage buckets, storage policies, aliases, workers, users, groups, roles and auth methods can be configured at global scope level. |
| Organization | The intermediate scope level, also referred to as organizations, are a child scope of global. Identity and access management related resources such as users, groups, roles and auth methods can be configured at the organization and global scope levels. |
| Project | The lowest scope level and a child scope of organization. It allows logical grouping of resources within an organization, such as targets, host catalogs, credentials stores and sessions. |
| Host catalog | A collection of hosts that Boundary can connect to, organized into host sets. |
| Host set | A subset of hosts within a host catalog which are considered equivalent for the purposes of access control. |
| Host | A resource with a network address reachable from Boundary, such as a server or database. |
| Target | A resource that ties network address information (via a direct address or by referencing host sets), credential libraries for injection or brokering (if desired) and port information to represent a networked service available for connection through Boundary. Targets also contain parameters, such as lifetime and connection count, to configure on the sessions created via authorization against the target.. A target can also be configured with ingress/egress worker filters that determine which workers are used to access targets. |
| Worker | A secure network proxy, enabling users to access private targets by establishing a direct network tunnel between the Boundary client on the user’s machine and the target systems. |
| User | A resource that represents an individual person or entity for the purposes of access control. A user can be associated with zero or more accounts. A user authenticates to Boundary through an associated account and must be associated with at least one account before they can access Boundary. |
| Group | A resource that represents a collection of principals, allowing them to be treated equally for access control purposes. As a principal itself, a group can be assigned to roles, and any role assigned to a group is indirectly assigned to all users within the group. A group can be defined at the global, organization, or project scope levels. |
| Managed group | A resource that represents a collection of accounts. The collection is formed by evaluating account information (e.g. LDAP groups, OIDC claims) defined by the auth method's identity provider against the managed group's configuration. An account can be associated with zero or more managed groups within the same auth method. It can be used as a principal in roles. |
| Role | A role is a collection of permissions granted to any principal assigned to it. Users, groups, and managed groups can be configured as principals in a role. |
| Authentication method | The mechanism by which users authenticate to Boundary. Can also be integrated with external identity providers like LDAP, Active Directory, or OIDC providers. |
| Account | A representation of a user's identity within a specific authentication method. Accounts can be created manually or automatically generated and are associated with a user in the same scope as the account’s auth method.. |
| Credential | Authentication details such as passwords, tokens, or keys used to access resources. |
| Credential store | Secure storage for managing and accessing credentials. This may be built-in to Boundary or contain information for accessing an external store like HashiCorp Vault. |
| Credential library | A collection of credentials of the same type from a single credential store that can be brokered or injected into the network session when users are accessing the networked services via sessions. |
| Session | A session is a set of related connections between a user and a host. A session may include a set of credentials which define the permissions granted to the user on the host for the duration of the session. Limits can be placed on the session, such as a maximum lifetime and/or a maximum connection count. |
| Session recordings | Recordings of user sessions for auditing and monitoring purposes. |
| Storage bucket | A container for storing session recordings and other data within Boundary. |
| Storage policy | Rules and configurations governing the management and retention of data within storage buckets. |
| Availability zone (AZ) | A distinct data center within a region that provides redundant and isolated infrastructure to ensure high availability and failover protection. Each region consists of multiple AZs to offer resilience against system failures. |
| Region | A geographically distinct area that hosts multiple data centers, providing redundancy and fault tolerance for cloud services. Each region consists of multiple, isolated locations known as Availability Zones. |
| Instance | A physical or virtual server or hardware unit used for computing purposes. |
| Load balancer | A hardware or software device used to distribute incoming network traffic across multiple servers. |
Use cases covered
This guide covers the Boundary features that consumer teams use once the platform is running:
| Use case | Summary |
|---|---|
| Transparent sessions | Seamless, passwordless access to authorized targets using aliases and the Boundary Client Agent. |
| Credential management | Accessing target credentials through Boundary credential brokering. Credential stores and libraries are configured by operators (see the Administration Guide). |
| Dynamic credentials | Using Vault-backed, ephemeral, time-bound credentials to access targets. The Boundary–Vault integration is configured by operators (see the Administration Guide). |
| Session recording | Viewing and playing back recorded sessions for compliance and incident investigation. Recording is enabled and managed by operators (see the Administration Guide). |
| Just-in-time approval | Requesting time-limited, on-demand access to targets through an approval workflow. |