# Pillar of Salt

Pillar is an interface for Salt designed to offer global values that can be distributed to all minions. Pillar data is managed in a similar way as the Salt State Tree.

Pillar was added to Salt in version 0.9.8

Note

Storing sensitive data

Unlike state tree, pillar data is only available for the targeted minion specified by the matcher type. This makes it useful for storing sensitive data specific to a particular minion.

## Declaring the Master Pillar

The Salt Master server maintains a pillar_roots setup that matches the structure of the file_roots used in the Salt file server. Like the Salt file server the `pillar_roots` option in the master config is based on environments mapping to directories. The pillar data is then mapped to minions based on matchers in a top file which is laid out in the same way as the state top file. Salt pillars can use the same matcher types as the standard top file.

The configuration for the `pillar_roots` in the master config file is identical in behavior and function as `file_roots`:

    pillar_roots:
      base:
        - /srv/pillar

This example configuration declares that the base environment will be located in the `/srv/pillar` directory. The top file used matches the name of the top file used for States, and has the same structure:

`/srv/pillar/top.sls`

    base:
      '*':
        - packages

This further example shows how to use other standard top matching types (grain matching is used in this example) to deliver specific salt pillar data to minions with different `os` grains:

    dev:
      'os:Debian':
        - match: grain
        - servers

`/srv/pillar/packages.sls`

    {% if grains['os'] == 'RedHat' %}
    apache: httpd
    git: git
    {% elif grains['os'] == 'Debian' %}
    apache: apache2
    git: git-core
    {% endif %}

Now this data can be used from within modules, renderers, State SLS files, and more via the shared pillar dict:

    apache:
      pkg:
        - installed
        - name: {{ pillar['apache'] }}

    git:
      pkg:
        - installed
        - name: {{ pillar['git'] }}

Note that you cannot just list key/value-information in `top.sls`.

## Pillar namespace flattened

The separate pillar files all share the same namespace. Given a `top.sls` of:

    base:
      '*':
        - packages
        - services

a `packages.sls` file of:

    bind: bind9

and a `services.sls` file of:

    bind: named

Then a request for the `bind` pillar will only return 'named'; the 'bind9' value is not available. It is better to structure your pillar files with more hierarchy. For example your `package.sls` file could look like:

    packages:
      bind: bind9

## Including Other Pillars

New in version 0.16.0.

Pillar SLS files may include other pillar files, similar to State files. Two syntaxes are available for this purpose. The simple form simply includes the additional pillar as if it were part of the same file:

    include:
      - users

The full include form allows two additional options -- passing default values to the templating engine for the included pillar file as well as an optional key under which to nest the results of the included pillar:

    include:
      - users:
          defaults:
            - sudo: ['bob', 'paul']
          key: users

With this form, the included file (users.sls) will be nested within the 'users' key of the compiled pillar. Additionally, the 'sudo' value will be available as a template variable to users.sls.

## Viewing Minion Pillar

Once the pillar is set up the data can be viewed on the minion via the `pillar` module, the pillar module comes with two functions, `pillar.items` and and `pillar.raw`. `pillar.items` will return a freshly reloaded pillar and `pillar.raw` will return the current pillar without a refresh:

    salt '*' pillar.items

Note

Prior to version 0.16.2, this function is named `pillar.data`. This function name is still supported for backwards compatibility.

## Pillar "get" Function

New in version 0.14.0.

The `pillar.get` function works much in the same way as the `get` method in a python dict, but with an enhancement: nested dict components can be extracted using a : delimiter.

If a structure like this is in pillar:

    foo:
      bar:
        baz: qux

Extracting it from the raw pillar in an sls formula or file template is done this way:

    {{ pillar['foo']['bar']['baz'] }}

Now, with the new `pillar.get` function the data can be safely gathered and a default can be set, allowing the template to fall back if the value is not available:

    {{ salt['pillar.get']('foo:bar:baz', 'qux') }}

This makes handling nested structures much easier.

Note

`pillar.get()` vs `salt['pillar.get']()`

It should be noted that within templating, the `pillar` variable is just a dictionary. This means that calling `pillar.get()` inside of a template will just use the default dictionary `.get()` function which does not include the extra `:` delimeter functionality. It must be called using the above syntax (`salt['pillar.get']('foo:bar:baz', 'qux')`) to get the salt function, instead of the default dictionary behavior.

## Refreshing Pillar Data

When pillar data is changed on the master the minions need to refresh the data locally. This is done with the `saltutil.refresh_pillar` function.

    salt '*' saltutil.refresh_pillar

This function triggers the minion to asynchronously refresh the pillar and will always return `None`.

## Targeting with Pillar

Pillar data can be used when targeting minions. This allows for ultimate control and flexibility when targeting minions.

    salt -I 'somekey:specialvalue' test.ping

Like with Grains, it is possible to use globbing as well as match nested values in Pillar, by adding colons for each level that is being traversed. The below example would match minions with a pillar named `foo`, which is a dict containing a key `bar`, with a value beginning with `baz`:

    salt -I 'foo:bar:baz*' test.ping

## Master Config In Pillar

For convenience the data stored in the master configuration file is made available in all minion's pillars. This makes global configuration of services and systems very easy but may not be desired if sensitive data is stored in the master configuration.

To disable the master config from being added to the pillar set `pillar_opts` to `False`:

    pillar_opts: False

Current Salt release: 0.17.1

### Table Of Contents

- Pillar of Salt
  - Declaring the Master Pillar
  - Pillar namespace flattened
  - Including Other Pillars
  - Viewing Minion Pillar
  - Pillar "get" Function
  - Refreshing Pillar Data
  - Targeting with Pillar
  - Master Config In Pillar

#### Previous topic

External Authentication System

#### Next topic

Master Tops System

### Quick search

Enter search terms or a module, class or function name.

### Upcoming SaltStack Events

My conferences on Lanyrd