Introduction
This document gives recommendations on how to Standardize on Boundary Enterprise as a shared service for your organization.
Hashicorp Validated Designs provide prescriptive guidance curated from our experience supporting numerous customer journeys with Boundary Enterprise.
Prerequisites
We recommend that you have completed the following steps before implementing the guidance in this document:
- Review: Boundary Operating Guide for Adoption
- Perform a maturity assessment/architecture review with our Solution Architecture team
Checklist
After completing the maturity assessment at the end of the adoption phase, you are ready to implement core portions of the standardization phase covered in this document.
While some parts of the standardizing maturity phase are optional and depend on the integrations your organization needs, we recommend adopting the following core capabilities at a minimum:
- Implement auditing to establish a system of record for user access and actions during remote sessions.
- Establish a workflow for periodic key rotation.
- Identify and prioritize use cases for:
- Integrating with Vault for on-demand, ephemeral credentials to access target networked services.
- Implementing session recording and storage policies according to your security and compliance requirements.
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 document covers the “Standardizing” phase of operating Boundary on the maturity scale and includes the following:
| Use Case | Summary |
|---|---|
| Credential management | A set of credentials is required when a user tries to access a remote machine. There are two types of credentials - static and dynamic. Credential management refers to the management of these static and dynamic credentials using the concepts of credential brokering or credential injection. Dynamic secrets/ credentials are generated on demand from HashiCorp Vault and are unique, instead of a static credential that is defined ahead of time and shared. Credential injection provides a passwordless experience for the user by fetching the credentials from a credential store and then passed on to a worker for authentication to a remote machine. Currently, only SSH credential injection is supported. |
| Audit logs | Audit events are considered an important principle of securing access to sensitive resources. Events are emitted for all requests and responses made to a Boundary Controller, every authentication attempt, and all upstream requests made from Workers to a Controller. This section describes the event types, support for sanitizing sensitive information and minimal configuration. |
| Session recording | Session Recording is used for compliance and threat management and can be enabled for supported targets. Boundary will automatically record the users session to allow authorized users to playback the recording. This section describes the architecture considerations required to support Boundary’s Session Recording capability. |
| Data encryption & key rotation | Improve security posture by regularly rotating data encryption keys |
| Just-in-time approvals | Just-in-time (JIT) approval workflows ensure that access is granted only when needed and for a limited duration. This reduces the risk of unauthorized access and potential security breaches. |
| Accessing private resources | Accessing resources within network segmentation or in complex network architectures with limited public accessibility |
| Automated target discovery | Methods for building out target host catalogs: Manual; Terraform, Dynamic. |
| Worker aware targets | Using worker tags and filters to direct which Boundary workers to use for proxied sessions. |