salt.pillar.vault

Vault Pillar Module

maintainer:

SaltStack

maturity:

New

platform:

all

New in version 2016.11.0.

This module allows pillar data to be stored in Hashicorp Vault.

Base configuration instructions are documented in the execution module docs. Below are noted extra configuration required for the pillar module, but the base configuration must also be completed.

After the base Vault configuration is created, add the configuration below to the ext_pillar section in the Salt master configuration.

ext_pillar:
  - vault: path=secret/salt

Each key needs to have all the key-value pairs with the names you require. Avoid naming every key 'password' as they will collide.

If you want to nest results under a nesting_key name use the following format:

ext_pillar:
  - vault:
      conf: path=secret/salt
      nesting_key: vault_key_name
$ vault write secret/salt auth=my_password master=127.0.0.1

The above will result in two pillars being available, auth and master.

You can then use normal pillar requests to get each key pair directly from pillar root. Example:

$ salt-ssh '*' pillar.get auth

Multiple Vault sources may also be used:

ext_pillar:
  - vault: path=secret/salt
  - vault: path=secret/root
  - vault: path=secret/minions/{minion}/pass
  - vault: path=secret/roles/{pillar[roles]}/pass

You can also use nesting here as well. Identical nesting keys will get merged.

ext_pillar:
  - vault:
       conf: path=secret/salt
       nesting_key: keyname1
  - vault:
       conf: path=secret/root
       nesting_key: keyname1
  - vault:
       conf: path=secret/minions/{minion}/pass
       nesting_key: keyname2

The difference between the return with and without the nesting key is shown below. This example takes the key value pairs returned from vault as follows:

path=secret/salt

Key             Value
---             -----
salt-passwd     badpasswd1

path=secret/root

Key             Value
---             -----
root-passwd     rootbadpasswd1

path=secret/minions/{minion}/pass

Key             Value
---             -----
minion-passwd   minionbadpasswd1
#Nesting Key not defined

local:
    ----------
    salt-passwd:
        badpasswd1
    root-passwd:
        rootbadpasswd1
    minion-passwd:
        minionbadpasswd1

#Nesting Key defined

local:
    ----------
    keyname1:
        ----------
            salt-passwd:
                badpasswd1
            root-passwd:
                rootbadpasswd1
    keyname2:
        ----------
            minion-passwd:
                minionbadpasswd1

New in version 3006.0: Pillar values from previously rendered pillars can be used to template vault ext_pillar paths.

Using pillar values to template vault pillar paths requires them to be defined before the vault ext_pillar is called. Especially consider the significancy of ext_pillar_first master config setting. You cannot use pillar values sourced from Vault in pillar-templated policies.

If a pillar pattern matches multiple paths, the results are merged according to the master configuration values pillar_source_merging_strategy and pillar_merge_lists by default.

If the optional nesting_key was defined, the merged result will be nested below. There is currently no way to nest multiple results under different keys.

You can override the merging behavior per defined ext_pillar:

ext_pillar:
  - vault:
       conf: path=secret/roles/{pillar[roles]}
       merge_strategy: smart
       merge_lists: false
salt.pillar.vault.ext_pillar(minion_id, pillar, conf, nesting_key=None, merge_strategy=None, merge_lists=None, extra_minion_data=None)

Get pillar data from Vault for the configuration conf.