Encrypted pillars & secrets

GPG-encrypted data and backends.

Advanced12 min · lesson 11 of 12

Pillar keeps sensitive data targeted, but on the master it still sits in plaintext files unless you encrypt it. Salt’s GPG renderer solves this: you encrypt secret values with the master’s GPG public key, store the ciphertext in pillar SLS (safe in Git), and the master decrypts at render time with its private key before delivering the value to entitled minions. It is Salt’s equivalent of Ansible Vault, SOPS, or Puppet’s eyaml.

GPG PILLAR SECRET LIFECYCLE

1Encrypt value

to the master's GPG public key

2Store ciphertext

in pillar SLS, safe in Git

3Master decrypts at render

with its private key

4Deliver to entitled minion

plaintext only to targeted minions

The master's private key decrypts every pillar secret — a single point of compromise; prefer an external backend like Vault.

pillar/secrets.sls

#!yaml|gpg
db:
  password: |
    -----BEGIN PGP MESSAGE-----
    hQEMA...ciphertext...        # encrypted to the master’s GPG key
    -----END PGP MESSAGE-----
# echo -n 'S3cr3t!' | gpg --armor --encrypt -r salt@master   produces this

External secret backends

For real secret management, Salt integrates with external stores through pillar and SDB (Salt Database): a Vault ext_pillar or the sdb:// URI fetches secrets from HashiCorp Vault at render time, so the source of truth stays in Vault and nothing durable lives in the Salt tree. This is the strongest pattern — Salt requests the secret when it needs it, with Vault handling rotation, audit, and access control.

master + usage

# /etc/salt/master — pull pillar from Vault
ext_pillar:
  - vault: path=secret/data/salt
# reference a secret via sdb in a state/pillar:
#   password: {{ salt['sdb.get']('sdb://myvault/secret/db/password') }}

The master’s decryption key protects everything

With the GPG renderer, the master’s private key decrypts every pillar secret — it is the single point of compromise, so guard it with tight permissions and treat the master as a crown-jewel host. Better still, prefer an external backend like Vault so secrets are fetched on demand and never stored (even encrypted) in your repo, with rotation and audit handled outside Salt.

salt-ssh & masterlessSecuring the Salt infrastructure