secrets-consumer-env_vault.md

secrets-consumer-env vault

Fetch and inject secrets from Vault to a given command

Synopsis

Fetch and inject secrets from Vault to a given command

Vault can store secrets in either KV v1 (no versions) or KV v2 (versioned secret), the API calls are on different paths and secrets-consumer-env will automatically adjust the secret path based on the secret backend version (v1 or v2)

secrets-consumer-env can login to kubernetes backend (default) or GCP backend.

Ways to use Vault secrets:

1. You can use Vault with a secret path that contains a JSON

2. You can use Vault paths as if they were a file system, one use case would be to have a path with secrets as sub-paths, each secret name would be used as the key name and will contain a single value, for example:

A list of secrets names (keys) secrets/kvV2/service/:

secrets/kvV2/service/API
|- value: qwerty1234`

secrets/kvV2/service/DATABASE_URL
|- value: http://127.0.0.1:3306

secrets/kvV2/service/SOME_PASSWORD
|- value: s3cr3t123

In this case we need the secret name to be the key, and the value to be the actual value for that key

Or it can be a list of secrets with multiple key values secrets/kvV2/service:

secrets/kvV2/service/app
|- API_KEY: qwerty1234
|- DATABASE_URL: http://127.0.0.1:3306

|- USER_NAME: admin
|- PASSWORD: s3cr3t

The advantage of this approach is that you don't have to read, and append a value when you want to add or edit a value in it

3. You can also use multiple secrets if you pass the flag --secret-config with following convention: {"path": "some/secrets/path/", "use-secret-names-as-keys": "true", version: "5"} multiple times

4. you can use explicit secrets by using the following convention: ENV_NAME_TO_BE_EXPORTED="secret:<SECRET_KEY>", only these variables will be available to your given command/process.

5. Vault secret path can be either treated as a directory by using a trailing slash "/" or it can be use as a wildcard for example: db*, *db, user

secrets-consumer-env vault [flags]

Options

  -b, --backend string                          Vault authentication backend [kubernetes, gcp] (default "kubernetes")
  -a, --google-application-credentials string   The file path to the GCP service account json file with permission to the secret
  -h, --help                                    help for vault
      --names-as-keys                           Use secret names as keys (default false)
      --path string                             Vault secrets path, can be a secret path ending with a "/" to get all secrets below that path
      --project-id string                       GCP Project ID for GCP backend login
      --role string                             Vault role (required)
      --secret-config stringArray               multiple secrets in JSON string like: '{"path": "/some/secret/path", "version": "3", "use-secret-names-as-keys":  true}' can be specified a multiple times
      --token-path string                       Kubernetes service account JWT token file path (default "/var/run/secrets/kubernetes.io/serviceaccount/token")
      --version string                          Secret version if using a KVv2 (default "latest")

Options inherited from parent commands

      --config string      config file (default is $HOME/.secrets-consumer-env.yaml)
  -v, --verbosity string   Log level (debug, info, warn, error, fatal, panic (default "info")

SEE ALSO

• secrets-consumer-env - Consume secrets from AWS, GCP or Hashicorp Vault

Auto generated by spf13/cobra on 29-Apr-2020