@ -61,7 +61,7 @@ When you connect to a target that uses Vault for dynamic SSH certificates, a new
Within Boundary, you can configure one or more credential stores. This could be a dedicated credential store per Boundary project, and/or multiple credential stores within the same Boundary project. You can either configure the credential store as static, which is Boundary's native store, or by integrating it with HashiCorp Vault. The purpose of the credential store that is integrated with Vault is to fetch secrets from Vault on behalf of Boundary users.
For organizations, there may be valid reasons for multiple credential stores within Boundary. As credential stores can only be created at the project level there may be different projects within an organization scope that have different requirements from their credential stores. An example may be within an organization scope you have two project scopes; Database and Compute. These two projects need to be isolated and therefore would have a dedicated credential store per project.
Organizations may have valid reasons for multiple credential stores within Boundary. As you can only create credential stores at the project level, there may be different projects within an org scope that have different requirements from their credential stores. For example, within an org scope you may have two project scopes: Database and Compute. These two projects need to be isolated and therefore would have a dedicated credential store per project.
With the integration with Vault, Boundary has to be assigned a periodic, renewable, orphan token from Vault. Each credential store that is created within Boundary that leverages Vault equates to one Vault token being created. The number of Boundary targets that source credentials from the stores, the number of users connecting to the targets, the number of sessions that get created, or how many credential libraries the credential store contains, all have no impact on the client count in Vault.
Danny Knights
2 years ago
committed by
GitHub