-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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: Add finer grained authorization for @runner, @job and @wheel in external_auth #19732
Comments
This would be great. There was a recent |
+1 |
That would be realy nice. (as explained in #26832: We have different teams and they would like to orchestrate deployements using salt. orchestrate runner seems like the perfect match for that but we need auth to limit/control which orchestrate sls can be run by users.) |
/cc @cachedout - relevant issue to our discussion yesterday about pattern matching on args in addition to runner/wheel functions. |
+1 |
4 similar comments
+1 |
+1 |
+1 |
+1 |
+1 I just spent a day getting salt-api working and understanding it, then realized if the account I'm using gets compromised, the account could use wheel to do things like alter the master config and probably a whole slew of other nasty things. This unfortunately isn't an acceptable security risk, especially when I only want the account to have access to wheel.key.gen_accept. |
Hello there... Bringing up this thread... I saw a similar feature was released in Boron (#29153) including the ability to limit args and kwargs but only to modules. Being able to do the same fine grained ACLs for runners and wheel would be totally awesome!! |
zd-913 |
Hi all, what's the status here? We could really use that "feature". No one here wants to implement that in the Nginx proxy before Cherrypy in Lua. |
@bemeyert, this Feature-Request is under active consideration for the Spring Feature-Release of Salt. Final decisions regarding which Feature-Requests that will be included in the Spring Feature-Release of Salt will be made in January-2017. Regards, |
@rickh563 ... as long as it's not released under "commercial license only" do you have any news? |
@hoitsang, this Feature would be delivered as part of open source Salt. |
Thank you @rickh563! Really looking forward to it! In the meantime I hope this hack will buy some time for everyone else, especially those of us who live at least 6 months behind the latest and greatest. In salt/utils/minions.py:
So that at the barebone we could grant wheel module level function call
Same story goes with runner_check() in the same module for @runner. |
ZD-1540 |
Let's make a prediction for the years to come : Oxygen -> Fluor ? |
#42729 updates Example: external_auth:
pam:
user_name:
- @runner: # or any of @runners, @wheel, @wheels
- 'module.function.*regex'
- 'module.another.*function':
args: ['a', 'b[cde]f']
kwargs:
'kwa': 'kwvalue'
# as well as
- @module:
- 'function.*regex':
args: ['and', 'so', 'on'] |
Thanks a bunch for this @DmitryKuzmenko!! |
@danlsgiga This will be available in the next feature release, |
Consider the following config:
I have pretty fine grained control over which functions Sarah can execute, but with @runner , @wheel and @job , it's a binary all or nothing.
I think it's pretty important to be able to have the same fine grained control as with execution modules.
I'm not sure exactly what that should look like, but maybe something like this?
In the above scenario I'm allowing Sarah to execute only the
myfunction
function in the myrunner.py runner and any function in themy_other_runner.py
runner. As well as only theaccept
function in the wheel's key module. (I didn't go verify that there is anaccept
function, but regardless, I'm sure you can see what I mean.)The text was updated successfully, but these errors were encountered: