Secrets

Filling

It is possible to ask secenv to fill secrets that are defined in the configuration file.

To define a secret, use the following code:

secrets:
  - secret: my_secret_1
    store: my_store
  - secret: my_secret_2
    store: my_store

It is not possible to have multiple secrets having the same name in the same store, reasons are fairly obvious, but it is possible for secrets to share the same name across multiple stores, like this:

secrets:
  - secret: my_secret
    store: my_store_1
  - secret: my_secret
    store: my_store_2

In this case, a secret called my_secret is created in both my_store_1 and my_store_2.

For some stores, secrets can be either a raw value (i.e. file content), or a key-value store like a JSON file (i.e. in AWS). To do so, use the following code:

secrets:
  - secret: my_kv_secret
    store: my_store
    keys:
      - key1
      - key2

The stores supporting key-value secrets are:

• AWS Secret Manager
• Hashicorp Vault
• Scaleway Secret Manager

For Hashicorp Vault, it is possible to specify the engine to use, to do so, add:

secrets:
  - secret: my_kv_secret
    store: my_vault_store
    engine: my_engine

Once everything is configured, run:

secenv secrets

For each secret defined in the configuration file (and for each key if some are provided), secenv will perform the following steps:

• If the secret doesn't exist, create it
• If the secret contains the keys parameter, do the following steps for each key
• If the secret/key is not empty, ask to overwrite it
• Ask for the value of the secret/key, or generate it
• Fill the secret (once with all the keys)

If the provided value starts with file:, secenv considers it must use the content of the file as the secret value, by example:

$ secenv secrets
Value for secret 'MY_SECRET' in store 'my_store'? file: /path/to/file

It is possible to generate secrets as well, to do so, use the following code:

secrets:
  - secret: my_secret
    store: my_store
    generate:
      type: <type>

For now, two types are available: password and dummy.

/!\ The dummy type is for debug purposes and fills the secret with the value password. DO NOT use it in production.

For the password type, it accepts the following parameters:

secrets:
  - secret: my_secret
    store: my_store
    generate:
      type: password
      length: <length> # defaults to 24
      alphabets:
        - <alphabet>

The alphabets are available in the string Python module. It defaults to string.printable without string.whitespace as it contains \t\r\n which can break a lot of things.

The alphabets shouldn't include the heading string.. In example, to use string.ascii_letters, add only ascii_letters in the alphabet list.

Note: it is possible to mix keys and generate, but the keys will all have the same type.

Syncing

It's also possible to sync the configuration file with the actual live secrets. Note that this won't create/delete/update the secrets, but only modify the configuration file.

To do so, run secenv sync. It's possible to sync just one store by using secenv sync $store.

The sync concerns the secrets and their keys.

A secret is considered to have keys if its value is parsable into a JSON dictionary.

By example, with the following configuration file:

# .secenv.yaml

stores:
  local:
    type: env

secrets:
  - secret: DB_CREDS
    store: local
    keys:
      - host

And this environment:

$ env
DB_CREDS='{"host": "db.domain.tld", "user": "admin", "password": "D34DB33F"}'

Then running secenv sync results in the following configuration file:

# .secenv.yaml

stores:
  local:
    type: env

secrets:
  - secret: DB_CREDS
    store: local
    keys:
      - host
      - user
      - password

Some remarks:

1. secenv will merge the specified and the detected keys
2. the content of the secrets doesn't matter, only the secret itself is considered
3. secenv will write down the new configuration, and backing-up the old one by adding a .bak suffix