Text Blame History Raw

Secret management and encryption

For all intents and purposes you should consider this repository to be publicly accessible, so please make sure to not expose any secret information (e.g. passwords) via state and configuration files.

Secret information (e.g. passwords) are managed in an encrypted way to provide confidentiality within this repository. In particular, we're using OpenPGP.

The Salt master has its own OpenPGP key and needs to be able to decrypt any secret for proper deployment. You'll find this key in the following file: gpg/B9D45B4366C69C8D75CA3A08F1C33B7A1346F48E.gpg.asc.

You'll need to import it manually, and won't find it on any public keyserver:

$ gpg --import gpg/B9D45B4366C69C8D75CA3A08F1C33B7A1346F48E.gpg.asc

You can then create new secrets using the following snippet:

$ echo -n "supersecret" | gpg --armor --batch --trust-model always --encrypt -r <KEY-name>

<KEY-name> should be a OpenPGP key handle and can be listed multiple times. For the recommended workflow (see below) you should use your own OpenPGP key handle, so that you will be able to decrypt the secret and can reencrypt it later on.

The output (OpenPGP armored ASCII text) can be included into any pillar:


a-secret: |
  Version: GnuPG v1

  -----END PGP MESSAGE-----

Recommended workflow

The recommended workflow for creating a new secret is as follows:

1.) Make sure to have all public keys from encrypted_pillar_recipients 2.) Encrypt the secret with your own public key 3.) Run the reencrypt_pillar.py script to re-encrypt it for all current recipients.


Whenever changing the list of recipients (i.e. adding new keys and/or removing keys) you need to reencrypt all pillar data. The recommended way of doing this is to use the reencrypt_pillar.py script in the following way:

$ ./bin/reencrypt_pillar.py --recipients-file encrypted_pillar_recipients -r pillar

To successfully run this script, you'll need to import all public keys as referenced in encrypted_pillar_recipients.

NOTE: Reencryption will only reencrypt the secrets in accordance with the current list of recipients. It will not change and/or update the secrets itself. Previous recipients might still be able to decrypt old versions of the encrypted pillar (version control!), so when appropriate, make sure to also change the secrets themselves.

More information & references

More information can be found here: