Salt Mine: area of visibility for collected data

[Friz-zy]

Currently all collected data can be fetched by any minion. Because of this Mine feature (and direct Peer Communication too) become unapplicable in setups with untrusted minions like multiple clients on one master or even multiple environments.

For example, ansible collect and share information only between hosts of current execution and any of this hosts and only them can get facts about other hosts. It's very convenient!

With salt currently we should hardcode data into pillar instead of dynamic lookups over group of hosts :(

There is old opened task that can explain typical situation

[gtmanfred]

Why can't publish.publish be used to tie this down and only let certain commands be run?

Daniel

[Friz-zy]

Because when you lock certain of commands, you doesn't lock number of hosts as arguments for this commands. Question not in commands but in virtual groups for minions

Like I have 3 minions, I want share data between 1 &2 but I don't want to let 3 know about 1 and 2 at all

Ansible can do it out of the box for example. With salt currently I should setup separate salt masters for first 2 minions and third one

[gtmanfred]

If the peering system could lock down to what options could be passed, would this solve the problem?

Thanks,
Daniel

[Friz-zy]

Possibly yes but for me this variant looks like a dirty hack in compare with the splitting Mine data. Because you can configure Mine one time on master and all necessary minions would know facts about other necessary minions by defaut, but with peering system you should additionally execute publish event

Imagine, that I want just populate /etc/hosts with hostname of some group of hosts, not all hosts.
With Salt Mine master config would be like:

mine_functions:
  'hypothetical group of hosts':
    network.ip_addrs:
      interface: eth0
  'another group of hosts': []

Then I can use this code:

{% for server, addrs in salt['mine.get']('hypothetical group of hosts', 'network.ip_addrs') | dictsort() %}
{{ addrs[0] }} {{ server }}
{% endfor %}

for 'hypothetical group of hosts' all should be fine, for 'another group of hosts' just nothing

How to convert it into clear state with peering system?

[gtmanfred]

@saltstack/team-core does anyone have any opinions about this proposal?

Thanks,
Daniel

[yagnik]

Given that mine_functions can be applied using pillar, can grains be used to lock down where the mine functions run and therefore help you group them, alternatively, we can also add different "names" using grains to support groups of mine functions ?

[Friz-zy]

Guys, again, main idea it's create groups of minions THAT DON'T KNOW ABOUT OTHER GROUPS!
All your variants - this is situation when minion would public info to all other minions.
Imagine, that people can use one salt master for applying configuration into minions from different clients or different groups of developers with different level of access or knowledge or NDA, whatever...

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[sathieu]

I think this bug is still relevant...

[stale]

Thank you for updating this issue. It is no longer marked as stale.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[mchugh19]

Still not stale

[stale]

Thank you for updating this issue. It is no longer marked as stale.

[github-abcde]

Does #55760 sufficiently address some of the concerns raised in this issue?

[Friz-zy]

Maybe :)
Thank you for mentioning
In short look, this changes just can lock a function to specific minions, prevent other from execution. This is a good security feature, no joks) But it doesn't split the visible areas as I understand.
Correct me if I'm wrong)
Can we split minions into the groups that can use the same function, but this function will return result depend on in which group requested host is located?

[github-abcde]

Minion-side ACL is not about preventing minions from executing specific functions, but it is about preventing other minions (implemented by allowing only specific minions) to get function data from the salt mine:
Any minion can still add any function (and the result from local execution of that function) to the salt mine. However, the big change is that along with the function and its result, a minion can now also specify which other minion(s) are allowed to get that result from the salt mine. If a minion is not allowed, it will receive no result (which is identical behavior as if the data was not present in the mine at all).
As such, if you have a nodegroup of minions, you can use that as a target (https://docs.saltstack.com/en/latest/topics/targeting/nodegroups.html) for which minions are allowed. For example:

salt $minion mine.send eth0_ip_addrs mine_function=network.ip_addrs eth0 allow_tgt='group1' allow_tgt_type=nodegroup

or

salt $minion mine.send eth0_ip_addrs mine_function=network.ip_addrs eth0 allow_tgt='N@group1' allow_tgt_type=compound

would make minion $minion store its eth0 IP address in the salt mine under the alias eth0_ip_addrs, and only allow minions in the nodegroup called group1 to access/retrieve it.
Since mine data is stored per minion (looking at the code in salt/daemons/masterapi.py), another minion can store the same function with a different ACL. However, I have not tested this, so this is purely theoretical for me at this point :)