SEP: Constrained Backends #71
Conversation
|
Hello! Thank you for submitting a Salt Enhancement Proposal! Our process is detailed in the README.md and more about the SEP Life-cycle. An Open Core Team member will be assigned to follow up and help guide this SEP soon and you will find the this in the Community Slack channel #sep. |
0000-constrained-backends.md
Outdated
|
|
||
| The last part, is still unpolished: | ||
| * Render (some) state files in a sandbox. | ||
| * Rendering itself can be harmful on the salt master, as the renderer (for example: py) might get access to data / pillars that is not in scope for the targeted minion. Restricting the information that is available. |
There was a problem hiding this comment.
This isn't true. State rendering happens on the minion. There's no way to access other minions' pillars.
There was a problem hiding this comment.
Sorry, my mixup. I corrected it.
Had originally in mind to call the minion a submaster of sorts.
There was a problem hiding this comment.
Seems like Github is not updating this PR with the latest commits i've pushed to my fork's master.
There was a problem hiding this comment.
Found a solution for githubs lack of PR updates: https://github.com/orgs/community/discussions/16351#discussioncomment-6327770 Sorry for the notification noise.
| Users able to change webserver.git aren't always the same users that should be able to modify backupservers. | ||
| - Apply these states constrained to be applied as user x. | ||
| - This and more could be accomplished by forcing a render pipeline, that acts as gateway that applies or filters wrapping the renderers with another renderer, that applies/filters parts. Or simply raise an exception to stop further processing of a configuration state. | ||
| - Allow just a certain list of renderers. |
There was a problem hiding this comment.
How does this help? Every renderer can run arbitrary commands as root.
There was a problem hiding this comment.
A wrapper can ensure that the input (the file from the file backend) and output of a rendering pipeline fits certain criteria. First scanning for arbitrary commands/functions/... in the state file and later checking for arbitrary commands/functions in the returned output.
Limiting the list of renderers should simply allow a salt administrator to concentrate on a limited set of features that should be allowed/denied/enforced - as you said every renderer can run arbitrary commands, but those can be issued with a particular format subset that a renderer can understand. I think, the py renderer would be excluded most of the time.
But you are correct for this, encapsulating a constrained renderer in a sandbox like environment would be favorable. Hence my suggestion to allow an salt administrator to sandbox the rendering within a renderer has only access to scoped data and limited acting room to have an effect on the host/minion.
0000-constrained-backends.md
Outdated
| - Examples of how the feature is used: | ||
| - Target minions on backends | ||
| Users able to change webserver.git aren't always the same users that should be able to modify backupservers. | ||
| - Apply these states constrained to be applied as user x. |
There was a problem hiding this comment.
How? Fork a minion process running as the target user to run it? Most stuff would break, such as communication with the master.
There was a problem hiding this comment.
"Target minions on backends" would modify (enable / disable) overlays of the fileserver on the base of targeting - which is controlled by the master. It would allow to create a "view" on a environment. This is maybe a feature on its own.
The latter "Apply these states constrained to be applied as user x" is tricky . as it would have to postprocess the output of a renderer, to ensure something like "runas" is set.
As for communication: The minion would have to act as proxy/filter for the unprivileged subprocess.
0000-constrained-backends.md
Outdated
| - Target minions on backends | ||
| Users able to change webserver.git aren't always the same users that should be able to modify backupservers. | ||
| - Apply these states constrained to be applied as user x. | ||
| - This and more could be accomplished by forcing a render pipeline, that acts as gateway that applies or filters wrapping the renderers with another renderer, that applies/filters parts. Or simply raise an exception to stop further processing of a configuration state. |
There was a problem hiding this comment.
Changing the rendering has no effect on the running of the rendered states.
There was a problem hiding this comment.
As the runtime can only run what it was given, i'll try to limit the output of the runtime by limiting the input of it.
Constraining Backends to allow collaboration with unprivileged users.