Reputation: 5
I am new to Salt. I have created a test environment with a master and one minion. I put information about a simple app in each of three pillars: base, dev and prod.
The minion is assigned to the "dev" environment so I expected it to see only "dev" and "base" pillars but it has access to everything. Isn't the environment supposed to control which states and which pillar data is available to the minions?
root_dir: /
autosign_file: /etc/salt/autosign.conf
file_roots:
base:
- /data/salt/states
dev:
- /data/salt/states/dev
prod:
- /data/salt/states/prod
pillar_roots:
base:
- /data/salt/pillar/base
dev:
- /data/salt/pillar/dev
prod:
- /data/salt/pillar/prod
'*':
- baseapp
'*':
- devapp
'*':
- prodapp
From minion:
dev
----------
baseapp:
----------
listen-on:
any
name:
base_app_config
port:
154
devapp:
----------
listen-on:
any
name:
dev_app_config
port:
155
prodapp:
----------
listen-on:
any
name:
prod_app_config
port:
153
I did not expect the dev minion to have access to prod pillar data. I hoped that making changes to files in states/prod and pillar/prod would never impact dev servers and vice versa.
Upvotes: 0
Views: 132
Reputation: 38777
The minion is assigned to the "dev" environment
Environment settings on the minion only set the default when none is specified. They can request data for any environment they want.
The default value of top_file_merging_strategy
is merge
. This gives you a final topfile of:
'*':
- baseapp
- devapp
- prodapp
That assigns all three pillars to every minion.
To restrict pillar data to specific minions, you need to use the top file to target them, ideally by their minion id:
base:
'*':
- baseapp
prod:
'prod-*':
- prodapp
dev:
'.*-(dev|test)$':
- match: pcre
- devapp
I note that you have autosign configured, which unless you are careful means you cannot even trust a minion's id, and attackers may be able to exfiltrate any of your pillar secrets.
Upvotes: 0