Renderer that will decrypt GPG ciphers

Any key in the SLS file can be a GPG cipher, and this renderer will decrypt it before passing it off to Salt. This allows you to safely store secrets in source control, in such a way that only your Salt master can decrypt them and distribute them only to the minions that need them.

The typical use-case would be to use ciphers in your pillar data, and keep a secret key on your master. You can put the public key in source control so that developers can add new secrets quickly and easily.

This renderer requires the gpg binary. No python libraries are required as of the 2015.8.0 release.

GPG Homedir

When running gpg commands, it is important to run commands as the user that owns the keys directory. If salt-master runs as user salt, then su salt before running any gpg commands.

To avoid compatibility and upgrade problems and to provide a standardized location for keys, salt uses /etc/salt/gpgkeys. In order to make the gpg command use this directory, use gpg --homedir /etc/salt/gpgkeys with gpg commands or set the homedir for that user using echo 'homedir /etc/salt/gpgkeys' >> ~/.gnupg.


To set things up, first generate a keypair. On the master, run the following:

# mkdir -p /etc/salt/gpgkeys
# chmod 0700 /etc/salt/gpgkeys
# gpg --gen-key --homedir /etc/salt/gpgkeys

Do not supply a password for the keypair, and use a name that makes sense for your application. Be sure to back up the gpgkeys directory someplace safe!


Unfortunately, there are some scenarios - for example, on virtual machines which don’t have real hardware - where insufficient entropy causes key generation to be extremely slow. In these cases, there are usually means of increasing the system entropy. On virtualised Linux systems, this can often be achieved by installing the rng-tools package.

Import keys to a master

If the keys already exist and need to be imported to the salt master, run the following to import them.

gpg --homedir /etc/salt/gpgkeys --import /path/to/private.key
gpg --homedir /etc/salt/gpgkeys --import /path/to/pubkey.gpg

Note: The default GPG Homedir <gpg-homedir> is ~/.gnupg and needs to be set using --homedir.

Adjust trust level of imported keys

In some cases, importing existing keys may not be enough and the trust level of the key needs to be adjusted. This can be done by editing the key. The key_id and the actual trust level of the key can be seen by listing the already imported keys.

gpg --homedir /etc/salt/gpgkeys --list-keys
gpg --homedir /etc/salt/gpgkeys --list-secret-keys

If the trust-level is not ultimate it needs to be changed by running

gpg --homedir /etc/salt/gpgkeys --edit-key <key_id>

This will open an interactive shell for the management of the GPG encryption key. Type trust to be able to set the trust level for the key and then select 5 (I trust ultimately). Then quit the shell by typing save.

Different GPG Location

In some cases, it's preferable to have gpg keys stored on removable media or other non-standard locations. This can be done using the gpg_keydir option on the salt master. This will also require using a different path to --homedir, as mentioned in the GPG Homedir <gpg-homedir> section.

gpg_keydir: <path/to/homedir>

Export the Public Key

# gpg --homedir /etc/salt/gpgkeys --armor --export <KEY-NAME> > exported_pubkey.gpg

Import the Public Key

To encrypt secrets, copy the public key to your local machine and run:

$ gpg --import exported_pubkey.gpg

To generate a cipher from a secret:

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

To apply the renderer on a file-by-file basis add the following line to the top of any pillar with gpg data in it:


Now with your renderer configured, you can include your ciphers in your pillar data like so:


a-secret: |
  Version: GnuPG v1

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

Encrypted CLI Pillar Data

New in version 2016.3.0.

Functions like state.highstate and state.sls allow for pillar data to be passed on the CLI.

salt myminion state.highstate pillar="{'mypillar': 'foo'}"

Starting with the 2016.3.0 release of Salt, it is now possible for this pillar data to be GPG-encrypted, and to use the GPG renderer to decrypt it.

Replacing Newlines

To pass encrypted pillar data on the CLI, the ciphertext must have its newlines replaced with a literal backslash-n (\n), as newlines are not supported within Salt CLI arguments. There are a number of ways to do this:

With awk or Perl:

# awk
ciphertext=`echo -n "supersecret" | gpg --armor --batch --trust-model always --encrypt -r | awk '{printf "%s\\n",$0} END {print ""}'`
# Perl
ciphertext=`echo -n "supersecret" | gpg --armor --batch --trust-model always --encrypt -r | perl -pe 's/\n/\\n/g'`

With Python:

import subprocess

secret, stderr = subprocess.Popen(
    ['gpg', '--armor', '--batch', '--trust-model', 'always', '--encrypt',
     '-r', ''],

if secret:
    print(secret.replace('\n', r'\n'))
    raise ValueError('No ciphertext found: {0}'.format(stderr))
ciphertext=`python /path/to/`

The ciphertext can be included in the CLI pillar data like so:

salt myminion state.sls secretstuff pillar_enc=gpg pillar="{secret_pillar: '$ciphertext'}"

The pillar_enc=gpg argument tells Salt that there is GPG-encrypted pillar data, so that the CLI pillar data is passed through the GPG renderer, which will iterate recursively though the CLI pillar dictionary to decrypt any encrypted values.

Encrypting the Entire CLI Pillar Dictionary

If several values need to be encrypted, it may be more convenient to encrypt the entire CLI pillar dictionary. Again, this can be done in several ways:

With awk or Perl:

# awk
ciphertext=`echo -n "{'secret_a': 'CorrectHorseBatteryStaple', 'secret_b': 'GPG is fun!'}" | gpg --armor --batch --trust-model always --encrypt -r | awk '{printf "%s\\n",$0} END {print ""}'`
# Perl
ciphertext=`echo -n "{'secret_a': 'CorrectHorseBatteryStaple', 'secret_b': 'GPG is fun!'}" | gpg --armor --batch --trust-model always --encrypt -r | perl -pe 's/\n/\\n/g'`

With Python:

import subprocess

pillar_data = {'secret_a': 'CorrectHorseBatteryStaple',
               'secret_b': 'GPG is fun!'}

secret, stderr = subprocess.Popen(
    ['gpg', '--armor', '--batch', '--trust-model', 'always', '--encrypt',
     '-r', ''],

if secret:
    print(secret.replace('\n', r'\n'))
    raise ValueError('No ciphertext found: {0}'.format(stderr))
ciphertext=`python /path/to/`

With the entire pillar dictionary now encrypted, it can be included in the CLI pillar data like so:

salt myminion state.sls secretstuff pillar_enc=gpg pillar="$ciphertext"


The default behaviour of this renderer is to log a warning if a block could not be decrypted; in other words, it just returns the ciphertext rather than the encrypted secret.

This behaviour can be changed via the gpg_decrypt_must_succeed configuration option. If set to True, any gpg block that cannot be decrypted raises a SaltRenderError exception, which registers an error in _errors during rendering.

In the Chlorine release, the default behavior will be reversed and an error message will be added to _errors by default.

salt.renderers.gpg.render(gpg_data, saltenv='base', sls='', argline='', **kwargs)

Create a gpg object given a gpg_keydir, and then use it to try to decrypt the data to be rendered.