Consider two approaches to distribute selected pillar keys to specific minion.
1. Top-file matcher using minion id.
In this case, top file has to know assignments of pillar sls files to their minions.
/srv/pillar/top.sls
:base: 'minion_1': - key1 'minion_2': - key2
/srv/pillar/key1.sls
:key1: value1
/srv/pillar/key2.sls
:key2: value2
2. Jinja conditional using if/else with minion id.
In this case, top file need to know nothing.
Instead, pillar sls files know themselves which minion can read them.
/srv/pillar/top.sls
:base: '*': - key1 - key2
/srv/pillar/key1.sls
:{% if grains['id'] == 'minion_1' %} key1: value1 {% endif %}
/srv/pillar/key2.sls
:{% if grains['id'] == 'minion_2' %} key2: value2 {% endif %}
Question
Are there any security preferences using the 1st or the 2nd approach?
Personally, I prefer the 2nd approach - it is more flexible (allows any logic in jinja templates). In the 1st approach, there is a problem - top-files are not templates and cannot be parameterized.
While writing this I also clarified an important Salt design aspect - pillar sls files are only compiled on Salt master in either cases (see this answer). Therefore, in both cases minions will never be given all pillar data anyway (to filter, select, and present resulted pillar for state rendering on their own). Compare it with states - AFAIK, they are rendered on minon side.
{% set server = salt['grains.get']('id').lower() %}
base:
'id:{{ server }}':
- match: grain
- {{ server }}
--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.