Pillar: secure per-minion data

Targeted, private configuration data.

Intermediate14 min · lesson 5 of 12

Pillar is Salt’s system for secure, targeted, per-minion data. Where states are shared code, pillar is the private data those states consume — a database password, a per-environment setting, a license key — and critically, the master only sends a given pillar value to the minions entitled to it. So a secret in pillar for the db group never reaches web minions. Pillar is defined on the master and assembled via its own top file.

TARGETED PILLAR DELIVERY

Master (pillar source)

pillar/top.sls

maps data to minions

db_secrets.sls

password, db host

db* minions (entitled)

Receive db_secrets

password + host delivered

web* minions (not entitled)

No db secrets

never receive db_secrets

The master sends a pillar value only to minions entitled to it — a too-broad target in the pillar top file leaks secrets.

pillar/top.sls + data

# pillar/top.sls — who gets what data
base:
  'db*':
    - db_secrets
---
# pillar/db_secrets.sls
db:
  password: 'S3cr3t!'      # only db* minions receive this
  host: 'db1.acme.internal'

state using pillar

db_config:
  file.managed:
    - name: /etc/app/db.conf
    - contents: |
        password={{ pillar['db']['password'] }}
    - show_changes: False       # keep the secret out of the change output

Why pillar matters for security

Two properties make pillar the right home for sensitive config. It is targeted, so data is only delivered to the minions that need it (least exposure), and it is separate from state code, so your logic stays generic and reusable while the secrets and per-node values live in controlled data. Combined with encryption (the GPG renderer, later) pillar is how you keep secrets out of your state tree and out of the wrong minions.

Pillar targeting is a security boundary — verify it

Because pillar controls who receives sensitive data, a too-broad target in the pillar top file leaks secrets to minions that should not have them. Check what a minion actually receives with salt ‘<id>’ pillar.items, scope pillar assignments as narrowly as possible, and never put secrets in grains or state files (which are not targeted the same way) thinking they are protected — only pillar delivers data selectively.

The top file & highstateGrains: minion facts