Details
-
Improvement
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
Description
Currently the input step allows you to specify a submitter, which may be a user ID or an external group ("granted authority"). This does not work well with authorization strategies, especially those that allow you to group together users inside Jenkins, such as (but not limited to) nectar-rbac in Jenkins Enterprise by CloudBees.
Arguably the more natural approach would be for InputStep to define a new permission, "approve flow", which would be checked on the WorkflowRun (can use PermissionScope.RUN). Thus rather than specifying a submitter for a particular step you would just ensure there was an RBAC group defined on the flow job (or its folder, etc.) which granted that permission and included the people you want. Then no reference need be made to any particular AuthorizationStrategy at all; this behavior would just follow from the Jenkins authorization model.
If defined, submitter would still be consulted in case the approving user lacked the new permission. There is a potential compatibility issue in case submitter was not defined; today that means that any user (even anonymous) can approve the flow, whereas we would want the new permission to be enforced. Unfortunately Jenkins offers no way to mark a newly introduced Permission as "granted until explicitly denied", except via system property hacks; see comment in JENKINS-17200. Lacking that, the only option is to break compatibility and say that existing input steps without submitter will now reject random users from approving. The new permission could be implied by, for example, Item.CONFIGURE to minimize the impact—approval by the person who wrote the flow would still be guaranteed to work.
Attachments
Issue Links
- is related to
-
JENKINS-17200 SCM.TAG permission not eagerly loaded
-
- Open
-
-
-
- Resolved
-
-
-
- Resolved
-
- links to
Activity
kshultz I am looking for this one. Thank you for your information. But how can we validate the password of that particular user ? and what about the abort restrictions ?
sai krishna
added a comment - - edited kshultz I am looking for this one. Thank you for your information. But how can we validate the password of that particular user ? and what about the abort restrictions ? Please would you be able to address the issue with RBAC stated in the description?
i.e.
"Currently the input step allows you to specify a submitter, which may be a user ID or an external group ("granted authority"). This does not work well with authorization strategies, especially those that allow you to group together users inside Jenkins, such as (but not limited to) nectar-rbac in Jenkins Enterprise by CloudBees."
I find that the 'submitter' attribute does not work on the input step. We are using Keycloak role-based AuthorizationStrategy. (Our code for the input step has not changed, but we recently changed Jenkins setup from a matrix based authorisation strategy to Keycloak).
Code below. Expected result is that if there is a user in Keycloak, it should verify that the logged in user matches. Similarly, if there is a group in Keycloak, the logged in user should be a member of the specified group.
isApproved = input(
id: 'someId',
message: 'Approve?',
submitter: 'someuser', // <== 'does not query Keycloak; ignores this
parameters: [choice(
choices: ['No', 'Yes'],
description: 'some description',
name: 'some name')]
) == 'Yes'
Jean-Pierre Fouche
added a comment - - edited Please would you be able to address the issue with RBAC stated in the description?
i.e.
"Currently the input step allows you to specify a submitter, which may be a user ID or an external group (" granted authority "). This does not work well with authorization strategies, especially those that allow you to group together users inside Jenkins, such as (but not limited to) nectar-rbac in Jenkins Enterprise by CloudBees."
I find that the 'submitter' attribute does not work on the input step. We are using Keycloak role-based AuthorizationStrategy. (Our code for the input step has not changed, but we recently changed Jenkins setup from a matrix based authorisation strategy to Keycloak).
Code below. Expected result is that if there is a user in Keycloak, it should verify that the logged in user matches. Similarly, if there is a group in Keycloak, the logged in user should be a member of the specified group.
isApproved = input(
id: 'someId' ,
message: 'Approve?' ,
submitter: 'someuser' , // <== 'does not query Keycloak; ignores this
parameters: [choice(
choices: [ 'No' , 'Yes' ],
description: 'some description' ,
name: 'some name' )]
) == 'Yes'
jglick I explicitly asked kshultz to leave a note here about some oddities he saw when testing my features – I think maybe there may be some confusion here, but the crux of the matter is that even admin permissions aren't enough to grant approval for an input step (even though you can rewrite the job totally with those permissions).
Feels like there was some miscommunication here, but in general this is just another facet of the feature request – adding integration of Jenkins permissions and roles into the input step approval process.