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.

There are two credential management paradigms in Boundary, credential brokering and credential injection.

Credential brokering

Credential brokering is the process by which credentials are fetched from a credential store, and then returned back to the user. The user must already be authorized to connect to a specific target to have credentials for that target brokered back to them. Credentials are brokered when the session is established.

The credential brokering process works as follows:

1. The user authenticates to Boundary using either the CLI or desktop app.

2. The user requests a connection to the target.

   The controller fetches credentials from the credential store and passes the credentials to the user.

3. The user establishes a connection to the session.

   The controller assigns the job to a worker, and the worker establishes a session to the target.

4. The user enters the credentials.

   The user is authenticated to the target.

You can attach brokered credentials to either TCP targets or SSH targets. Brokered credentials can take the form of a token, username and password, SSH private key, certificate, JSON blob, or an unstructured secret stored in Vault, for example.

Security considerations

Consider a scenario where a user wants to access a target using SSH.

In this scenario, the user must be authorized to access the target. If they are authorized, they can authenticate themselves to the machine using credentials that were brokered, or returned, back to them. If the user is not authorized to access the target, they will not be able to retrieve brokered credentials for that target.

If a user wants to abstract the authentication process using brokered credentials, they can use the boundary connect ssh-style command, and pass credentials to sshpass, PuTTY, or another such tool. In this scenario, while the brokered credential may not be visible to the user, they still interact with the brokered credentials to perform authentication.

Additionally, with Vault's dynamic secrets engine, an administrator could configure their environment such that secrets are essentially one-time passwords, as the credentials are revoked after the session is terminated.

Learn more about credential brokering.

Learn more about the Vault dynamic secrets engine.

Credential injection ^HCP/ENT

Credential injection is the process by which a credential is fetched from a credential store and then passed on to a worker for authentication to a remote machine. With credential injection, the user never sees the credential required to authenticate to the target. This provides a passwordless experience for the user, as the worker does both session establishment and authentication to the target on behalf of the user. This process differs from credential brokering, where credentials are returned to the user rather than injected into the session on worker nodes.

The credential injection process works as follows:

1. The user authenticates to Boundary.

2. The user requests a connection to a target.

   The controller fetches credentials from the credential store.

3. The user establishes a connection to the session.

   The controller assigns the job to a worker, and the worker establishes a session to the target. Then the controller passes credentials to the worker. The worker authenticates to the target, and the user is then authenticated to the target.

Credential injection is available for the SSH target type, allowing users to inject the following credential types when accessing targets using SSH:

• SSH certificates
• Usernames and passwords
• Usernames and public keys

Security considerations

Consider a scenario where a user wants to access a target using SSH.

In this scenario, the user must be authorized to access the target. If they are authorized, they have the ability to connect to the worker. Upon connecting to the worker, the worker attempts to establish a remote session to the target, and attempts authentication on behalf of the user.

If the user is not authorized to access the target, the credentials are not injected on their behalf, nor are the credentials brokered back to them.

Learn more about credential injection.