Configure a secret provider
A secret provider stores the connection and authentication settings for your external secrets manager. After you register a provider, you can create secret aliases that point to secrets within it.
For providers not covered here, including Vault KV v1 and IAM-authenticated Vault, see Configure a custom plugin provider.
Before you begin
- Itential Gateway installed and running
- Network access from the gateway server to your secrets manager
- Authentication credentials stored as files on the gateway server
Never pass credentials as command-line values. Store tokens, certificate files, and private keys on disk and reference them by file path.
All communications between Gateway and your secrets manager use TLS 1.3+.
HashiCorp Vault, token authentication
Use token authentication for Vault deployments with long-lived tokens. For short-lived tokens, use AppRole authentication instead.
If your token expires, secret retrieval fails until you update the token file. For short-lived tokens, use AppRole authentication.
HashiCorp Vault, AppRole authentication
AppRole authentication uses a role ID and a secret ID stored in separate files. Gateway handles token refresh automatically.
Unlike the secret ID, the role ID is passed as a literal value with --role-id, not a file path. Role IDs are not treated as sensitive by Vault, but the secret ID must always be supplied as a file using --secret-id-file.
When Vault rotates your secret ID, update the file on disk. Gateway picks up the new value automatically on its next authentication cycle.
CyberArk Central Credential Provider (CCP)
CyberArk CCP uses mutual TLS. Store the client certificate and private key as files on the gateway server.