Cloud providers
This page lists the cloud providers supported as secret providers
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 the section on how to avoid passing credentials on the commandline and how to protect against outages.
Setting up and using either of the vaults described here is outside the scope of this document.
HashiCorp Vault
The implementation for HashiCorp Vault 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.
Other options for hcv://
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.
Amazon Secret Manager
The provider for AWS Secret Manager 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 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.
Google Cloud Secret Manager
The secret provider for Google Cloud Secret Manager relies on the Google Cloud SDK to handle the authentication. Follow the steps to get the environment authenticated with Google. After the athentication is complete, the configuration is:
If you need to integrate with a different flow you can also supply an access token, but notice that the token may be short-lived and you cannot change the token after configuring the secret provider:
Additional options for gcsm://
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.
Azure Key Vault
With Azure Key Vault as the provider there are several options for authenticating, where the most secure method is to use the Azure CLI login that handles all the details. Since this method is the default, the secret provider can be configured as:
Instead of supplying the name of the keyvault, the full vault url can be supplied with &vault-uri=.
Manually authenticating
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:
Last updated