[JIRA] [workflow-plugin] (JENKINS-27134) Permission for input approval, or choice of Jenkins-specific group as submitter

[jglick@cloudbees.com (JIRA)]

Jesse Glick updated an issue

Jenkins / JENKINS-27134 Permission for input approval, or choice of Jenkins-specific group as submitter Change By: Jesse Glick Summary: Permission for input approval , or choice of Jenkins-specific group as submitter Add Comment

This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)

[pwolf@cloudbees.com (JIRA)]

Patrick Wolf updated an issue

Jenkins / JENKINS-27134 Permission for input approval, or choice of Jenkins-specific group as submitter

Change By: Patrick Wolf Labels: api  followup  permissions

Add Comment

[dbeck@cloudbees.com (JIRA)]

Daniel Beck updated an issue

Jenkins / JENKINS-27134 Permission for input approval, or choice of Jenkins-specific group as submitter

Change By: Daniel Beck Labels: api followup new-permission permissions

Add Comment

This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)

[jglick@cloudbees.com (JIRA)]

Jesse Glick updated an issue

Jenkins / JENKINS-27134 Permission for input approval, or choice of Jenkins-specific group as submitter

Change By: Jesse Glick Component/s: pipeline-input-step-plugin Component/s: pipeline

Add Comment

[jenkins@uhp-software.com (JIRA)]

UHP commented on JENKINS-27134

Re: Permission for input approval, or choice of Jenkins-specific group as submitter Is this also connected to the Role Strategy Plugin? Or is it already possible to use a role defined with the Role Strategy Plugin as submitter?

Add Comment

[jglick@cloudbees.com (JIRA)]

Jesse Glick commented on JENKINS-27134

Re: Permission for input approval, or choice of Jenkins-specific group as submitter

If either of the extension points I proposed in my last comment were defined, then the Role Strategy plugin could in principle implement it. A CloudBees employee working on this would presumably focus on implementing it in the RBAC plugin that is included in CJP, though it would not be a bad idea to try two implementations to vet the API design for poor assumptions. I would tend to prefer the first one as it is more generic. The practical difficulty is that actually defining it in core would prevent uptake from plugins (both pipeline-input-step, the caller, and implementers such as nectar-rbac or role-strategy) for months after this was merged, unless we use some tricks such as commenting out @Override in the implementations and having the caller look it up reflectively pending a newer core dep.

Add Comment

[sam.mxracer@gmail.com (JIRA)]

Sam Gleske commented on JENKINS-27134

Re: Permission for input approval, or choice of Jenkins-specific group as submitter

This proposal is not good for how my team works. We don't want "one person or group of people" to approve all parts of the pipeline. There's a whole approval process at my place of work (like Dev deployer, QA teams deploying, and an entire separate permission for production deployments). The current behavior is good enough. I don't see any advantage as to why you'd want this to be a specific permission unless you plan on creating a multi-permission structure for each individual input step (which to me sounds like overkill compared to the current behavior).

Add Comment

[sam.mxracer@gmail.com (JIRA)]

Sam Gleske edited a comment on JENKINS-27134

Re: Permission for input approval, or choice of Jenkins-specific group as submitter

-1 vote

This proposal is not good for how my team works.  We don't want "one person or group of people" to approve all parts of the pipeline.  There's a whole approval process at my place of work (like Dev deployer, QA teams deploying, and an entire separate permission for production deployments).  The current behavior is good enough.  I don't see any advantage as to why you'd want this to be a specific permission unless you plan on creating a multi-permission structure for each individual input step (which to me sounds like overkill compared to the current behavior).

Add Comment

[sam.mxracer@gmail.com (JIRA)]

Sam Gleske edited a comment on JENKINS-27134

Re: Permission for input approval, or choice of Jenkins-specific group as submitter

-1 vote This proposal is not good for how my team works.  We don't want " one person or a group of people " to approve all parts of the pipeline.  There's a whole approval process at my place of work (like Dev deployer, QA teams deploying, and an entire separate permission for production deployments).  The current behavior is good enough.  I don't see any advantage as to why you'd want this to be a specific permission unless you plan on creating a multi-permission structure for each individual input step (which to me sounds like overkill compared to the current behavior).

Add Comment

[sam.mxracer@gmail.com (JIRA)]

Sam Gleske edited a comment on JENKINS-27134

Re: Permission for input approval, or choice of Jenkins-specific group as submitter

-1 vote This proposal is not good for how my team works.  We don't want one person or a group of people to approve all parts of the pipeline.  There's a whole approval process at my place of work (like Dev deployer, QA teams deploying, and an entire separate permission for production deployments).  The current behavior is good enough.  I don't see any advantage as to why you'd want this to be a specific permission unless you plan on creating a multi-permission structure for each individual input step (which to me sounds like overkill compared to the current behavior).

My team does not use RBAC in Jenkins Enterprise.  How would this affect other authorization strategies?

Add Comment

[jglick@cloudbees.com (JIRA)]

Jesse Glick commented on JENKINS-27134

Re: Permission for input approval, or choice of Jenkins-specific group as submitter

I don't see any advantage as to why you'd want this to be a specific permission Nor is that currently being proposed. The proposal is simply to extend the permitted values of “submitter” to include not just user IDs and external (e.g., LDAP) groups, but also “Jenkins-local” groups defined by any authorization strategy implementing a new SPI.

The current behavior is good enough.

Great, then you need not worry.

Add Comment

[jglick@cloudbees.com (JIRA)]

Jesse Glick commented on JENKINS-27134

Re: Permission for input approval, or choice of Jenkins-specific group as submitter

actually defining it in core would prevent uptake from plugins stephenconnolly proposes some mechanism TBD whereby the API could be defined in core for the long term, with a copy in some plugin permitting it to be used in the near term without a new core dependency. This has been done in the past for certain other APIs, though it can be tricky depending on the case.

Add Comment

[jeanpierrefouche@gmail.com (JIRA)]

Jean-Pierre Fouche commented on JENKINS-27134

Re: Permission for input approval, or choice of Jenkins-specific group as submitter

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 has not changed, but we recently changed from a matrix based authorisation strategy to Keycloak).

Add Comment

This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)

[jeanpierrefouche@gmail.com (JIRA)]

Jean-Pierre Fouche edited a comment on JENKINS-27134

Re: Permission for input approval, or choice of Jenkins-specific group as submitter

Please would you be able to address the issue with RBAC stated in the description? i.e.

{code:java} "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."{code} 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).

Add Comment

[jeanpierrefouche@gmail.com (JIRA)]

Jean-Pierre Fouche edited a comment on JENKINS-27134

Re: Permission for input approval, or choice of Jenkins-specific group as submitter

Please would you be able to address the issue with RBAC stated in the description? i.e.  {code:java} "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."{code} 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. {code:java} isApproved = input(         id: 'applyPlan',         message: 'Approve?',         submitter: 'someuser', // <== 'does not query Keycloak; ignores this          parameters: [choice(                 choices: ['No', 'Yes'],                 description: config.description,                 name: config.name)] ) == 'Yes' {code}

Add Comment

[jeanpierrefouche@gmail.com (JIRA)]

Jean-Pierre Fouche edited a comment on JENKINS-27134

Re: Permission for input approval, or choice of Jenkins-specific group as submitter

Please would you be able to address the issue with RBAC stated in the description? i.e.  {code:java} "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."{code} 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. {code:java} isApproved = input(

id: ' applyPlan someId ',

message: 'Approve?',         submitter: 'someuser', // <== 'does not query Keycloak; ignores this          parameters: [choice(                 choices: ['No', 'Yes'],

description: 'some description',                 name: 'some name')] ) == 'Yes' {code}

Add Comment

[jeanpierrefouche@gmail.com (JIRA)]

Jean-Pierre Fouche edited a comment on JENKINS-27134

Re: Permission for input approval, or choice of Jenkins-specific group as submitter

Please would you be able to address the issue with RBAC stated in the description? i.e.  {code:java} "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."{code} 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. {code:java} isApproved = input(

id: 'applyPlan',

message: 'Approve?',         submitter: 'someuser', // <== 'does not query Keycloak; ignores this          parameters: [choice(                 choices: ['No', 'Yes'],

description: config. 'some description ' ,                 name: config. 'some name ' )] ) == 'Yes' {code}

Add Comment

[jeanpierrefouche@gmail.com (JIRA)]

Jean-Pierre Fouche edited a comment on JENKINS-27134

Re: Permission for input approval, or choice of Jenkins-specific group as submitter

Please would you be able to address the issue with RBAC stated in the description? i.e.  {code:java} "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."{code} 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.

{code:java} 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' {code}

Add Comment