Credential management

When users connect to a remote machine, they typically need a set of credentials for authentication. After they connect to the machine, they may also require another set of credentials to access services or other machines within the network.

In Boundary, there are three main concepts concerning credential management:

• Credential
• Credential Store
• Credential Library

Credential

A credential is a data structure containing one or more secrets that binds an identity to a set of permissions or capabilities.

A credential:

• Can be of static or dynamic type
• May be a Boundary resource
• Belongs to one and only one credential store
• Can be associated with zero or more targets directly if it is a resource
• Can be associated with zero or more libraries directly if it is a resource
• Is deleted when the credential store or credential library it belongs to is deleted

Credential store

A credential store is a resource that can retrieve, store, and potentially generate credentials of differing types and access levels. It belongs to a project and supports mechanisms that ensure credentials abide by the principle of least privilege. A credential store can also contain credential libraries.

A credential store:

• Is a Boundary resource
• Can belong to one and only one scope
• Owns zero or more credentials
• Owns zero or more credential libraries
• Is deleted when the scope it belongs to is deleted

In HashiCorp Boundary, credential stores are used to store and manage the credentials required to access various targets. Boundary supports different types of credential stores to accommodate various use cases and credential types.

The primary types of credential stores in Boundary are:

• Static credential stores
• Dynamic credential stores/ Vault credential store

Static credential stores are built into Boundary and only store static credentials (i.e.username and password, ssh-private key and json)

Static credential stores support the following credential types:

• Username password
• SSH private key
• SSH certificate
• JSON

Vault credential stores utilize a HashiCorp Vault instance, which provides additional capabilities such as generating ephemeral credentials.

Credential library

A credential library provides credentials for sessions. All credentials returned by a library must be equivalent from an access control perspective, i.e. any user leveraging these credentials from the same library must have the same access to a target. A credential library manages the lifecycle of the credentials it returns. For dynamic secrets, this includes creation, renewal, and revocation. Rotating credentials include check-out, check-in, and rotation of secrets. The system retrieves credentials from a library for a session and notifies the library when the session has been terminated. A credential library belongs to a single credential store.

Vault credential libraries are the Boundary resource that maps to Vault secrets engines. A single credential store may have multiple types of credential libraries. For example, the Vault credential store might include separate credential libraries corresponding to each Vault secret engine backend.

A credential library:

• Is a Boundary resource
• Belongs to one and only one credential store
• Can be associated with zero or more targets
• Can contain zero or more credentials
• Is deleted when the credential store it belongs to is deleted

Architecture

App target types can be associated with static or dynamic credential stores. SSH target types can have either injected credentials or brokered credentials whereas generic TCP target types can only have brokered credentials. Both dynamic and static credentials can be brokered or injected. More information about injected credentials and brokered credentials will be discussed in the following section..

Organizations may have valid reasons for using multiple credential stores within Boundary. You can only create credential stores at the project scope, and each project can contain multiple credential stores. Projects within an org scope may have different requirements from their credential stores. For example, within an org scope, you may have two projects: Database and Compute. These two projects may need to be isolated and can have a dedicated credential store per project.