Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: Clarify credential workflow for SSH target types #5082

Merged
merged 3 commits into from
Sep 11, 2024
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion website/content/docs/concepts/credential-management.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -88,7 +88,7 @@ The credential injection process works as follows:
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:
Credential injection is required for the SSH target type, allowing users to inject the following credential types when they access targets using SSH:

- SSH certificates
- Usernames and passwords
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,8 @@ When you use credential brokering, Boundary returns credentials to the user when

## Requirements

- You must have an existing target available.
- You must have an existing target available. To use brokered credentials to connect to a target that runs SSH, you must use a TCP target type.

- You must have configured either a static credential store or a Vault credential store:

- To configure a static credential store, refer to [Create static credential stores](/boundary/docs/configuration/credential-management/static-cred-boundary).
Expand Down Expand Up @@ -66,4 +67,12 @@ Complete the following steps to configure credential brokering for a target:
</Tip>

</Tab>
</Tabs>
</Tabs>

## More information

Refer to the following topics for more information:

- [Create static credential stores](/boundary/docs/configuration/credential-management/static-cred-boundary)
- [Create Vault credential stores](/boundary/docs/configuration/credential-management/static-cred-vault)
- [Target types](/boundary/docs/concepts/domain-model/targets#target-types)
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,8 @@ Credential injection provides end users with a passwordless experience when they
## Requirements

- This feature requires either <a href="https://www.hashicorp.com/products/boundary">HCP Boundary or Boundary Enterprise</a>
- You must have an existing target available.
- You must have an existing target available. To use injected application credentials to connect to a target that runs SSH, you must use an SSH target type.
Dan-Heath marked this conversation as resolved.
Show resolved Hide resolved

- You must have configured either a static credential store or a Vault credential store:

- To configure a static credential store, refer to [Create static credential stores](/boundary/docs/configuration/credential-management/static-cred-boundary).
Expand Down Expand Up @@ -70,4 +71,12 @@ Complete the following steps to configure targets with credential injection:
</Tip>

</Tab>
</Tabs>
</Tabs>

## More information

Refer to the following topics for more information:

- [Create static credential stores](/boundary/docs/configuration/credential-management/static-cred-boundary)
- [Create Vault credential stores](/boundary/docs/configuration/credential-management/static-cred-vault)
- [Target types](/boundary/docs/concepts/domain-model/targets#target-types)
Original file line number Diff line number Diff line change
Expand Up @@ -27,9 +27,14 @@ Boundary can retrieve credentials from the credential stores and present them ba

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, see the [credential brokering](/boundary/docs/concepts/credential-management#credential-brokering) concepts page.
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](/boundary/docs/concepts/credential-management#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, see the [credential injection](/boundary/docs/concepts/credential-management#credential-injection) 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](/boundary/docs/concepts/credential-management#credential-injection) concepts page.

The type of target you connect to also determines which credential workflows you can configure.
An SSH target must have at least one injected application credential to establish the SSH connection.
A TCP target cannot have any injected application credentials.
For more information, refer to the [Target types](/boundary/docs/concepts/domain-model/targets#target-types) documentation.

## Next steps

Expand Down
Loading