Cloud providers
This page lists the cloud providers supported as secret providers
Last updated
Was this helpful?
This page lists the cloud providers supported as secret providers
Last updated
Was this helpful?
For cloud-based providers there is generally a need to pass some kind of credentials to access the storage as well as the possibility of a provider being unavailable for a shorter period. To address these two issues, see and .
Setting up and using either of the vaults described here is outside the scope of this document.
The implementation for supports both the cloud-based offering as well as the self-hosted version as sources.
To connect to the vault, provide the url as part of the configuration:
The url is converted to the url used to connect to the vault (e.g., https://localhost:8200 in this example). The token is used to authenticate, and the secrets are the vaults that secrets are read from.
In the cloud-based offering the "secrets" values shown here are referred to as Apps and in the CLI as "mount points". When more than one value is supplied, the vaults are tried in order and stops once all secrets are resolved. This means that if the same secret key is found in two vaults, the value will be used from the first vault examined.
hcv://For development purposes, the url can use a http connection by setting &connection-type=http , but this should not be used in production.
To connect using a credential pair instead of the token, the credentials can be provided with the values client-id and client-secret , but should be passed via the environment variables:
By default, the key lookup is done case-insensitive but can be toggled case-sensitive with the option &case-sensitive=true.
The secrets values name the vaults to use (called "Secret Name" in the AWS Console). When more than one value is supplied, the vaults are tried in order and stops once all secrets are resolved. This means that if the same secret key is found in two vaults, the value will be used from the first vault examined.
Instead of suppling the region the entire service point url can also be provided via &service-url=.
By default, the key lookup is done case-insensitive but can be toggled case-sensitive with the option &case-sensitive=true.
gcsm://By default, the screts are accessed with the version set to latest but this can be changed with &version=. Finally, the communication protocol can be changed from gRPC to https with by adding &api-type=Rest.
Instead of supplying the name of the keyvault, the full vault url can be supplied with &vault-uri=.
Instead of relying on the autmated login handling, it is possible to authenticate with either a client credential, or a username/password pair.
For authenticating with client credentials, use:
And for username/password, use:
The provider for supports the AWS hosted vault. The credentials for the vault are the regular Access Key Id and Access Key Secret. While these can be provided via the secret provider url as access-id and access-key, they should be passed via the environment variables:
The secret provider for relies on the to handle the authentication. Follow with Google. After the athentication is complete, the configuration is:
If you need to integrate with a different flow you can also , but notice that the token may be short-lived and you cannot change the token after configuring the secret provider:
With as the provider there are several options for authenticating, where the most secure method is to use the that handles all the details. Since this method is the default, the secret provider can be configured as: