SaltStack, like any good configuration management system, provides a way to distribute sensitive data (like passwords or API keys) to minion nodes in a secure manner. This is supported by the Pillar system, where this data can be added to a tree-like data structure and are then made available to the relevant minions. While this "distribution" of data is secure, "adding" pillar entries still works (at least by default) by editing YAML-formatted plain text files. This means places like the salt master node and the source code repository containing the state/pillar tree are a weak spot, since there's no at-rest encryption for the included pillars.

One solution is to encrypt the pillars using GPG. This requires GnuPG, and works using a public/private keypair where the secrets are encrypted using the public key, and the salt master decrypts them using the private key.

GPG Renderer

Salt supports using renderers which define how data from a given file should be extracted. By default this is set to yaml, but renderers can also be combined using pipes (|). So something like yaml|gpg means pass the input first to the YAML renderer, take the output, and then feed it to the GPG renderer.

The GPG renderer decrypts GPG ciphers. It works by first generating a public/private keypair, and then using the public key to encrypt secrets. These encrypted values are then added to the pillar tree instead of the plain text secrets. The salt master node can then decrypt these values using the private key. This ensures that the pillar data is also encrypted at rest.

Generating keys

The first step is to generate the keypair that will be used for encrypting/decrypting secrets. The following commands (and the rest of the commands in this article) should be run on the salt master node.

$ sudo mkdir /etc/salt/gpgkeys
$ sudo chmod 0700 /etc/salt/gpgkeys
$ sudo gpg --gen-key --homedir /etc/salt/gpgkeys

Now that the keypair is generated, we can export the public key that will be used to encrypt pillars.

$ sudo gpg --homedir /etc/salt/gpgkeys --export --armor > /path/to/public.key

Placing this public key alongside the state/pillar tree in version control is a good idea, so that other developers on the team can add secrets too.

Adding encrypted pillars

To encrypt stuff, the public key needs to first be imported into the development environment.

$ gpg --import /path/to/public.key

The gpg command can now be used to encrypt values.

$ echo -n "hunter2" | gpg --armor --batch --trust-model always --encrypt -r key-name

This prints out a long and cryptic looking string on the terminal, which is the encrypted secret that should be added to the pillar tree.


    key: |
        -----BEGIN PGP MESSAGE-----
        Version: GnuPG v1

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

With some delay (that Salt takes to refresh pillars automatically), requesting the pillar value for app:key should now show the decrypted value.

$ sudo salt '*' pillar.get app:key