Credentials in Boundary
Connecting to a target normally means a user must know its credentials. Boundary removes that requirement by centralizing credential storage. It can broker or inject credentials automatically, so users never have to manage them directly. This page explains Boundary's credential management model. Refer to the linked pages below for the steps to create a credential store or configure brokering and injection.
Credential stores
Boundary supports credential management using credential stores, which are resources that store credentials for various targets.
Boundary supports two types of credential stores:
| Store type | What it stores | Best for |
|---|---|---|
| Static | Username password, username password domain, or keypairs | Credentials Boundary manages natively |
| Vault | Any secret in Vault's KV engine, including dynamic credentials | Short-lived credentials, LDAP (Lightweight Directory Access Protocol)/Active Directory integration |
Boundary can retrieve credentials from the credential stores and present them back to the user when they connect to targets. This workflow is referred to as credential brokering. Boundary can also inject credentials directly into the session on behalf of the user (a passwordless workflow). This workflow is referred to as credential injection.
End user workflows
End users can experience three workflows when they connect to a target. In the first workflow, when an end user connects to a target, Boundary initiates the session, but the end user must know the credentials to authenticate into the session. This workflow is available for testing purposes, but it is not recommended because it places the burden on the users to securely store and manage credentials.
The second workflow uses a feature called credential brokering, where credentials are retrieved from a credentials store and returned back to the end user. The end user then enters the credentials into the session when prompted by the target. This workflow is more secure than the first workflow since credentials are centrally managed through Boundary. For more information, refer to the the Credential brokering concepts page.
The third workflow uses a featured called credential injection, where credentials are retrieved from a credential store and injected directly into the session on behalf of the end user. This workflow is the most secure because credentials are not exposed to the end user, reducing the chances of a leaked credential. This workflow is also more streamlined as the user goes through a passwordless experience. For more information, refer to the Credential injection concepts page.
The type of target you connect to also determines which credential workflows you can configure:
- TCP targets cannot have any injected application credentials
- SSH targets must have at least one injected application credential to establish the SSH connection
- RDP targets must have at least one injected application credential to establish the RDP connection
For more information, refer to the Target types documentation.
Credential types
Boundary supports several credential types to accommodate different authentication methods:
- Username password: Basic username and password authentication
- Username password domain: Username, password, and domain for Windows environments that use Active Directory authentication
- SSH private key: SSH private key authentication
- SSH certificate: SSH certificate-based authentication
- JSON: Flexible JSON-based credential storage
Next steps
The following pages provide steps to configure static credentials using both a static credential store and a Vault credential store. You can also configure targets for either credential brokering or credential injection workflows.