Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[JENKINS-13190] AuthorizationStrategyOverride #2481
Otherwise, plugins that want to provide their own additional ACL rules have to implement
This replaces #412:
Outline of the change:
Known issues and notes:
A screenshot of the Configure Global Secury page:
I'm very aware about performance impact of such approach. Even if there is no extension points added, there is some logic like extension point retrieval and overriding of Strategies in each permission check. IMHO all this logic should be launched if and only if there is an extension point implementation.
I think following 4 ways for JENKINS-35081
I prefer them in the order of A-1, B and C.
I hope this clarifies why I want this feature for JENKINS-35081.
Actually it doesn't clarify at all to me.
In my view of JENKINS-35081 you just add a new Action to jobs for called
So currently the Action menu looks like
With JENKINS-35081 you just move the configuration of the authorization from the job's Configure screen to this other screen. (You can store the authorization in a side file and use a reconfigurable property so that config.xml POSTs etc will not.)
So we have something like
Now it is not the authorize project plugin's responsibility to start tweaking the job configuration permissions. The system administrator should use their authorization strategy to lock the job down if they want the job locked down.
Admins grant EXTENDED_READ to users that are allowed to view a jobs configuration. You should not be stopping that.
Admins grant CONFIGURE to users that are allowed to configure jobs. You should not be stopping that.
The authorize project plugin should stick to a single responsibility principle.
Having said all that, I am not against JENKINS-13190, I just completely fail to see how it is blocking or necessary in any way to implement JENKINS-35081 (which should be just adding a new action and moving the configuration so that anyone viewing the job configuration will be able to have credentials drop-downs respect the authentication that the job will run as)
But once we remove the driver of JENKINS-35081 then I think we can probably approach JENKINS-13190 the right way... and then if we have a JENKINS-13190 implementation there could be an additional helper plugin that would use an implementation of JENKINS-13190 to layer on restrictions on the ACLs of projects under specific conditions - one of which could be enabling authorize project plugin being enabled for that job
I hope this clarifies what my query is
I plan to provide an alternate feature for "No need for re-authentication" of
On the other hand, I still think that it's useful to provide an option to restrict CONFIGURE (or may be EXTENDED_READ) only to a user configured with authorize-project.
@ikedam I view the concern you have as being defects in the Authorization Strategy implementations.
Having had a decent Authorization Strategy since 2011 (RBAC) which allows filtering out roles and adding them back in easily, there would be no requirement for these changes.
But more importantly, from our experience with the RBAC strategy, it is critical to provide a way for at least admins to see what the effective permissions are on any item where the permissions can be changed. This is why in the RBAC strategy we provide the Roles summary:
So an additional issue I see with this proposed change is that it does not include a mechanism for at least administrators to figure out what is going on in a consistent way.
I guess what I am leaning towards is that we probably need to enhance the AuthorizationStrategy API to include an extension point for explaining effective permissions if we are going to start adding layers of permission modifications, and as such I suspect I am
(note that the mechanism can be a hidden action much like the
@stephenc It's strange that I'm requested to do something for a plugin in Jenkins Enterprise, isn't it? It's a business of Cloudbee.
Though, I think I could get what you point.
They cause difficulties of administration and performance of Jenkins.
And they are actually the points where I had difficulties to implement this change.
I think above issues can be resolved in following ways:
Let me know how do you think this idea.
Well actually I was going to implement the config screen stuff if you indicated that you were in agreement with the idea
I suspect the OSS role strategy plugin could be made to give same, but as I don't use it, I cannot speak to that.
Also, as I said, I am not against fixing ACL, I just do not see it blocking separation of job authorisation config from main config so that everyone can actually have credentials selection that reflects the permissions that the job runs as.
Role Strategy does not support this feature right now. Long story.
For OSS there is a semi-implemented plugin here: https://github.com/ksenia-nenasheva/security-inspector-plugin (not ready for production). CC @ksenia-nenasheva. Maybe needs finalization.
I'm not sure we want to have permission visualization engine inside the core
I thought over JENKINS-13190 again, and I still believe I need a feature for plugins to block configuration by unexpected users.
I'll reform the feature and recreate the pull request.
Thanks for all the review.