From 520980e72e8ccdb7e2f6373c9ef9cfda4f41cb33 Mon Sep 17 00:00:00 2001 From: Dan Heath <76443935+Dan-Heath@users.noreply.github.com> Date: Fri, 6 Sep 2024 13:48:54 +0000 Subject: [PATCH 1/3] backport of commit ba0c53f566299be7ed0b8bd4e1c306fecee9e04e --- .../content/docs/concepts/credential-management.mdx | 2 +- .../configure-credential-brokering.mdx | 13 +++++++++++-- .../configure-credential-injection.mdx | 13 +++++++++++-- .../configuration/credential-management/index.mdx | 9 +++++++-- 4 files changed, 30 insertions(+), 7 deletions(-) diff --git a/website/content/docs/concepts/credential-management.mdx b/website/content/docs/concepts/credential-management.mdx index 128f618ab9..423325e683 100644 --- a/website/content/docs/concepts/credential-management.mdx +++ b/website/content/docs/concepts/credential-management.mdx @@ -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 diff --git a/website/content/docs/configuration/credential-management/configure-credential-brokering.mdx b/website/content/docs/configuration/credential-management/configure-credential-brokering.mdx index d589cb6d8c..3829f99981 100644 --- a/website/content/docs/configuration/credential-management/configure-credential-brokering.mdx +++ b/website/content/docs/configuration/credential-management/configure-credential-brokering.mdx @@ -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). @@ -66,4 +67,12 @@ Complete the following steps to configure credential brokering for a target: - \ No newline at end of file + + +## 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) \ No newline at end of file diff --git a/website/content/docs/configuration/credential-management/configure-credential-injection.mdx b/website/content/docs/configuration/credential-management/configure-credential-injection.mdx index b1cf39fd82..75f613c70b 100644 --- a/website/content/docs/configuration/credential-management/configure-credential-injection.mdx +++ b/website/content/docs/configuration/credential-management/configure-credential-injection.mdx @@ -15,7 +15,8 @@ Credential injection provides end users with a passwordless experience when they ## Requirements - This feature requires either HCP Boundary or Boundary Enterprise -- 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. + - 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). @@ -70,4 +71,12 @@ Complete the following steps to configure targets with credential injection: - \ No newline at end of file + + +## 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) \ No newline at end of file diff --git a/website/content/docs/configuration/credential-management/index.mdx b/website/content/docs/configuration/credential-management/index.mdx index 54392c1189..e0ab55b775 100644 --- a/website/content/docs/configuration/credential-management/index.mdx +++ b/website/content/docs/configuration/credential-management/index.mdx @@ -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 From 833bf65b9bcc713093d2d074f72bc0b76ca879d2 Mon Sep 17 00:00:00 2001 From: stellarsquall Date: Mon, 9 Sep 2024 17:21:26 +0000 Subject: [PATCH 2/3] backport of commit 13c6160ee25f74ca425eb8dc7e18177ed763ff6d --- .../docs/concepts/credential-management.mdx | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/website/content/docs/concepts/credential-management.mdx b/website/content/docs/concepts/credential-management.mdx index 423325e683..9a7f934277 100644 --- a/website/content/docs/concepts/credential-management.mdx +++ b/website/content/docs/concepts/credential-management.mdx @@ -17,7 +17,9 @@ To configure credential brokering or credential injection with static credential ## 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: @@ -28,10 +30,10 @@ The credential brokering process works as follows: The controller fetches credentials from the credential store and passes the credentials to the user. 1. 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. + The controller assigns the job to a worker, and the worker establishes a session to the target. 1. The user enters the credentials. - The user is authenticated to the target. + 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. @@ -44,6 +46,7 @@ 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. This feature requires HCP Boundary or Boundary Enterprise 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. @@ -81,12 +86,12 @@ The credential injection process works as follows: 1. The user authenticates to Boundary. 1. The user requests a connection to a target. - The controller fetches credentials from the credential store. + The controller fetches credentials from the credential store. 1. 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. + 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 required for the SSH target type, allowing users to inject the following credential types when they access targets using SSH: @@ -94,6 +99,8 @@ Credential injection is required for the SSH target type, allowing users to inje - Usernames and passwords - Usernames and public keys +Additional credentials can be brokered to SSH targets after the session is establised using injected credentials. + ### Security considerations Consider a scenario where a user wants to access a target using SSH. From d4bd33d84a313404c349334cdf275c037f4425d9 Mon Sep 17 00:00:00 2001 From: Dan Heath <76443935+Dan-Heath@users.noreply.github.com> Date: Mon, 9 Sep 2024 21:06:31 +0000 Subject: [PATCH 3/3] backport of commit 85070b075c9873ab9f9b4734641a083fb0a2d4a2 --- .../credential-management/configure-credential-injection.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/content/docs/configuration/credential-management/configure-credential-injection.mdx b/website/content/docs/configuration/credential-management/configure-credential-injection.mdx index 75f613c70b..6c76b3868a 100644 --- a/website/content/docs/configuration/credential-management/configure-credential-injection.mdx +++ b/website/content/docs/configuration/credential-management/configure-credential-injection.mdx @@ -15,7 +15,7 @@ Credential injection provides end users with a passwordless experience when they ## Requirements - This feature requires either HCP Boundary or Boundary Enterprise -- 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. +- You must have an existing target available. If you use the SSH target type, the target must be configured with an injected application credential. - You must have configured either a static credential store or a Vault credential store: