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.
Scope
This Administration Guide covers the ongoing, day-2 management of a Boundary Enterprise deployment: identity and access administration, consumer onboarding, observability and alert management, audit log management, and scheduled maintenance such as backups, disaster recovery testing, and upgrades. It assumes the Boundary Installation Guide has been completed and the system is running. For configuring Boundary features and use cases, see the Boundary User Guide.
Prerequisites
HashiCorp recommends the following prerequisites before using the Boundary Administration Guide:
- Review Cloud Operating Model
- Deploy Boundary Enterprise following the Boundary Installation Guide
- Attend a Boundary workshop
HashiCorp recommends using Terraform to provision and configure Boundary. For guidance on using Terraform, please refer to the Terraform HVD.
Checklist
Once the Boundary Enterprise deployment is running and handed over from installation, you are ready to implement the day-2 operational practices covered in this guide.
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. Configure resources such as storage buckets, storage policies, aliases, workers, users, groups, roles and auth methods at global scope level. |
| Organization | The intermediate scope level, also referred to as organizations, are a child scope of global. Configure IAM-related resources such as users, groups, roles and auth methods 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 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 be optionally configured with ingress/egress worker filters that determine which workers to use 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. It is possible to associate a user with zero or more accounts. A user authenticates to Boundary through an associated account and associated with at least one account before they can access Boundary. |
| Group | A group is a principal; assign these to roles. Any role assigned to a group is indirectly assigned to all users within the group. Defined a group at the global, organization, or project scope levels. |
| Managed group | A resource that represents a collection of accounts. Form the collection by evaluating account information (for example LDAP groups, OIDC claims) defined by the auth method's identity provider against the managed group's configuration. Associate an account with zero or more managed groups within the same auth method. Optionally use these as principals in roles. |
| Role | A role is a collection of permissions granted to any principal assigned to it. Configure users, groups, and managed groups as principals in a role. |
| Authentication method | The mechanism by which users authenticate to Boundary via external identity providers such as LDAP, Active Directory, or OIDC providers. |
| Account | A representation of a user's identity within a specific authentication method. Manually or automatically create accounts and associate them 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 either internally to Boundary or to an external store such as HashiCorp Vault. |
| Credential library | A collection of credentials of the same type. Broker or inject a single credential library 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. Optionally place limits 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 fail-over 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. |
What this guide covers
This guide covers the day-2 administration of Boundary Enterprise and includes the following:
| Section | Summary |
|---|---|
| People and process | The platform operating model, team responsibilities, and workflows for running Boundary as an internal platform service. |
| Identity and access management | Ongoing administration of identities, groups, roles, and policies, including operator onboarding and periodic access reviews. |
| Consumer onboarding | The runbook for onboarding new consumer teams and applications, including creating isolation boundaries and granting access. |
| Observability and alert management | Day-2 monitoring: metrics to watch, alert interpretation and response, dashboards, and APM vendor integration. |
| Audit log management | Day-2 operations for audit logs, including verifying delivery, retention, streaming, and responding to findings. |
| Backup and restore operations | Verifying scheduled backups, restoring from snapshots, and testing restore procedures. |
| Disaster recovery operations | Scheduled failover tests, promotion and failback runbooks, and RPO/RTO validation. |
| Upgrade procedures | Upgrading Boundary controllers and workers with minimal disruption, including pre-checks and rollback. |
| Support readiness | Preparing for and engaging HashiCorp support, including diagnostics and escalation paths. |