Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
plakun opened this issue Dec 2, 2024 · 5 comments
Open

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

plakun opened this issue Dec 2, 2024 · 5 comments
Labels
Feature new functionality including changes to functionality and code refactors, etc. needs-triage

Comments

@plakun
Copy link

plakun commented Dec 2, 2024

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.

@plakun plakun added Feature new functionality including changes to functionality and code refactors, etc. needs-triage labels Dec 2, 2024
Copy link

welcome bot commented Dec 2, 2024

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:

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 [email protected]. We’re glad you’ve joined our community and look forward to doing awesome things with you!

@OrangeDog
Copy link
Contributor

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
Copy link

orlovds commented Dec 6, 2024

@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
Copy link
Contributor

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
Copy link
Collaborator

"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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature new functionality including changes to functionality and code refactors, etc. needs-triage
Projects
None yet
Development

No branches or pull requests

4 participants