forked from cyberark/secretless-broker
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Support Vault backend KVv2. Connected to cyberark#1331.
Signed-off-by: Michael Meijer <[email protected]>
- Loading branch information
1 parent
b3c42e3
commit ef22559
Showing
6 changed files
with
222 additions
and
20 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,94 @@ | ||
# Vault Provider | ||
|
||
The Vault provider for Secretless can fetch secrets from configured backends | ||
in [HashiCorp Vault](https://www.vaultproject.io). The provider is based on | ||
the [Vault API client](https://pkg.go.dev/github.com/hashicorp/vault/api) in Go. | ||
It reads values from the configured paths. | ||
|
||
## Usage Documentation | ||
|
||
The Vault provider is configured in the `secretless.yml` using: | ||
```yaml | ||
from: vault | ||
get: /path/to/secret/in/vault | ||
``` | ||
for the credentials in the | ||
service connector configuration. Note that Vault supports various backends | ||
that store different kinds of secrets. The Vault provider supports: | ||
cubbyhole, KV v1 and KV v2. It may support other secret engines of Vault, specifically | ||
those whose reading of secret at given path yields value at given field, i.e. similar | ||
to the cubbyhole and KV secret engines. | ||
The provider will read a secret at a given path and returns the value of the field | ||
`value` (by default) from the secret. By appending `#fieldName` to the path, the | ||
provider will instead read the value at the field `fieldName`. For example: | ||
`/path/to/secret#fieldName`. By prepending the backend name `kv-v2:` to the path, | ||
the provider will change the way it handles the secret returned by the Vault client. | ||
This is due to the KV v2 backend behaving differently in Vault. For example: | ||
`kv-v2/path/to/secret`. This variant supports explicit field name too, e.g. | ||
`kv-v2/path/to/secret#fieldName`. Please keep in mind that the path to the secret | ||
in KV v2 has a `data` segment in the path in Vault, e.g. `secret/data/to/my/secret`. | ||
This is specific to the KV v2 backend. | ||
|
||
Below are some examples showing how to configure the provider for secrets. | ||
|
||
### Example: API key from KV backends (v1 and v2) | ||
|
||
Here's an excerpt of an example configuration for a fictional "Example Service" | ||
that requires an API key, e.g. used in a request header. It gets the API key | ||
from Vault's KV version 1 backend at path `kv/example-service` | ||
under the secret's `value` field. | ||
|
||
```yaml | ||
version: 2 | ||
services: | ||
my_example_service: | ||
connector: generic_http | ||
listenOn: tcp://0.0.0.0:8080 | ||
credentials: | ||
apikey: | ||
from: vault | ||
get: kv/example-service # path to API key in Vault, field 'value' holds the API key | ||
... | ||
``` | ||
|
||
A slightly different configuration explicitly sets the field `api-key` | ||
(instead of the default `value`) to hold the API key. | ||
|
||
```yaml | ||
version: 2 | ||
services: | ||
my_example_service: | ||
connector: generic_http | ||
listenOn: tcp://0.0.0.0:8080 | ||
credentials: | ||
apikey: | ||
from: vault | ||
get: kv/example-service#api-key # path to API key in Vault, field 'api-key' holds the API key | ||
... | ||
``` | ||
If the secret is stored in a KV v2 backend (mounted at `secret` by default), | ||
the configuration must use the `kv-v2:` prefix to tell the provider to | ||
behave accordingly when reading the secret. | ||
|
||
```yaml | ||
version: 2 | ||
services: | ||
my_example_service: | ||
connector: generic_http | ||
listenOn: tcp://0.0.0.0:8080 | ||
credentials: | ||
apikey: | ||
from: vault | ||
get: kv-v2:secret/data/example-service#api-key # path to API key in Vault, field 'api-key' holds the API key | ||
... | ||
``` | ||
|
||
## Limitations | ||
|
||
- Only token-based login to Vault supported at the moment. | ||
- Due to differences in e.g. the Vault KV version 1 and 2 backends, a prefix | ||
to the path is required to instruct Secretless to handle retrieval | ||
appropriately. | ||
- Backends that have multiple values change simultaneously (e.g. client | ||
id and secret, or database username and password) are not supported at the moment. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters