[FEATURE REQUEST] pillar protection from being exposed via salt-call

[plakun]

Is your feature request related to a problem? Please describe.
When using pillars propagated to minions, it is necessary to restrict access to them via a salt-call on the host. This is necessary if an organisation has a complex permission system and, for example, the host administrator should not have access to sensitive data propagated through pillars.

Describe the solution you'd like
Add an option to pillar sls file that will protect variables from being exposed via salt-call. In this case command "salt-call pillar.items" shows only pillars that don't have this option.

[welcome[bot]]

Hi there! Welcome to the Salt Community! Thank you for making your first contribution. We have a lengthy process for issues and PRs. Someone from the Core Team will follow up as soon as possible. In the meantime, here’s some information that may help as you continue your Salt journey.
Please be sure to review our Code of Conduct. Also, check out some of our community resources including:

• Community Wiki
• Salt’s Contributor Guide
• Join our Community Slack
• IRC on LiberaChat
• Salt Project YouTube channel
• Salt Project Twitch channel

There are lots of ways to get involved in our community. Every month, there are around a dozen opportunities to meet with other contributors and the Salt Core team and collaborate in real time. The best way to keep track is by subscribing to the Salt Community Events Calendar.
If you have additional questions, email us at saltproject@vmware.com. We’re glad you’ve joined our community and look forward to doing awesome things with you!

[OrangeDog]

If someone has root on a minion, they can read everything on the minion. That includes pillar data in the memory of the salt-minion process. Preventing them from using salt-call pillar.items will not prevent them from accessing the sensitive data on the hosts that they administer.

The only solutions are:
a) Do not give administrator access to people you do not trust.
b) Do not allow sensitive data to ever exist on the hosts they administer.

[orlovds]

@OrangeDog
can at least introduce masking of sensitive data, for example

data:
----------
ipa_server_password:
 *****

Should a person with root rights on a VM see the secrets of specific applications?

[OrangeDog]

There is masking if you use pillar.obfuscate instead of pillar.items.

A person with root rights on a VM can see all secrets on that VM (regardless of whether Salt is involved). If you think they should not then you need to not give them root rights.

[whytewolf]

"complex permission system" is just a way of saying it is badly designed. people have too much control over systems they shouldn't have any kind of access to. if they shouldn't have access to the pillar data the shouldn't have access to salt-call. period. there is way more security at stake then just what they can read in pillars if they can access salt-call.

such as oh i can't read the password in pillar but hey i can change the password in the app cause salt can access pillar, and it can change that password. or, hey i don't need access to the password cause salt-call knows it and can pull the information directly.

obfuscating pillar is about as useful as putting a band aid on a severed arm.

[dwoz]

There is masking if you use pillar.obfuscate instead of pillar.items.

A person with root rights on a VM can see all secrets on that VM (regardless of whether Salt is involved). If you think they should not then you need to not give them root rights.

@OrangeDog, are you able to join our discord server please? https://discord.gg/J7b7EscrAs