• Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Major Major
    • github-oauth-plugin
    • None

      Background

      We are operating Jenkins in an enterprise where we have Slave to Master control in place.

      Unfortunately this plugin doesn't allow mapping GitHub users to Agent/* permissions (aside from matrix auth, but that causes us to lose Committer Authorisation Strategy which we love).

      So we are currently are forced to make agent users into Jenkins Admins, which undermines Slave to Master controls.

      The Feature

      We would like to add a new configuration, agentUserNames.

      This would behave in the same way as adminUserNames does now (example), however only for Agent/* permission checks.

      This means that any usernames declared in agentUserNames will short-circuit the ACL checking function if it is for an Agent/* permission.

      A Question

      As this is currently blocking us, we are planning to implement the above feature in a fork of this plugin. We wanted to ask early on, whether it sounds like an OK solution and something we could contribute via a PR when we are done?

       

          [JENKINS-63421] Agent/Connect and other Agent permissions

          Andreas Nygard created issue -
          Andreas Nygard made changes -
          Summary Original: Manage Agent/Connect and other Agent permissions New: Agent/Connect and other Agent permissions
          Andreas Nygard made changes -
          Description Original: *Background*

          We are operating Jenkins in an enterprise where we have [Slave to Master control|https://wiki.jenkins.io/display/JENKINS/Slave+To+Master+Access+Control] in place.

          Unfortunately this plugin doesn't allow mapping GitHub users to {{Agent/*}} permissions (aside from matrix auth, but that causes us to lose Committer Authorisation Strategy which we love).

          So we are currently are forced to make agent users into Jenkins Admins, which undermines Slave to Master controls.

          *The Feature*

          We would like to add a new configuration, {{agentUserNames}}.

          This would behave in the same way as {{[adminUserNames|https://github.com/jenkinsci/github-oauth-plugin/blob/master/src/main/java/org/jenkinsci/plugins/GithubRequireOrganizationMembershipACL.java#L92]}} does now, however only for Agent/* permission checks.

          This means that any usernames declared in the {{agentUserNames}} will short-circuit the ACL checking function if it is for an {{Agent/*}} permission.

          *A Question*

          As this is currently blocking us, we are planning to implement the above feature in a fork of this plugin. We wanted to ask early on, whether it sounds like an OK solution and something we could contribute via a PR when we are done?

           
          New: *Background*

          We are operating Jenkins in an enterprise where we have [Slave to Master control|https://wiki.jenkins.io/display/JENKINS/Slave+To+Master+Access+Control] in place.

          Unfortunately this plugin doesn't allow mapping GitHub users to {{Agent/*}} permissions (aside from matrix auth, but that causes us to lose Committer Authorisation Strategy which we love).

          So we are currently are forced to make agent users into Jenkins Admins, which undermines Slave to Master controls.

          *The Feature*

          We would like to add a new configuration, {{agentUserNames}}.

          This would behave in the same way as {{adminUserNames}} ([example|https://github.com/jenkinsci/github-oauth-plugin/blob/master/src/main/java/org/jenkinsci/plugins/GithubRequireOrganizationMembershipACL.java#L92]) does now, however only for Agent/* permission checks.

          This means that any usernames declared in the {{agentUserNames}} will short-circuit the ACL checking function if it is for an {{Agent/*}} permission.

          *A Question*

          As this is currently blocking us, we are planning to implement the above feature in a fork of this plugin. We wanted to ask early on, whether it sounds like an OK solution and something we could contribute via a PR when we are done?

           
          Andreas Nygard made changes -
          Description Original: *Background*

          We are operating Jenkins in an enterprise where we have [Slave to Master control|https://wiki.jenkins.io/display/JENKINS/Slave+To+Master+Access+Control] in place.

          Unfortunately this plugin doesn't allow mapping GitHub users to {{Agent/*}} permissions (aside from matrix auth, but that causes us to lose Committer Authorisation Strategy which we love).

          So we are currently are forced to make agent users into Jenkins Admins, which undermines Slave to Master controls.

          *The Feature*

          We would like to add a new configuration, {{agentUserNames}}.

          This would behave in the same way as {{adminUserNames}} ([example|https://github.com/jenkinsci/github-oauth-plugin/blob/master/src/main/java/org/jenkinsci/plugins/GithubRequireOrganizationMembershipACL.java#L92]) does now, however only for Agent/* permission checks.

          This means that any usernames declared in the {{agentUserNames}} will short-circuit the ACL checking function if it is for an {{Agent/*}} permission.

          *A Question*

          As this is currently blocking us, we are planning to implement the above feature in a fork of this plugin. We wanted to ask early on, whether it sounds like an OK solution and something we could contribute via a PR when we are done?

           
          New: *Background*

          We are operating Jenkins in an enterprise where we have [Slave to Master control|https://wiki.jenkins.io/display/JENKINS/Slave+To+Master+Access+Control] in place.

          Unfortunately this plugin doesn't allow mapping GitHub users to {{Agent/*}} permissions (aside from matrix auth, but that causes us to lose Committer Authorisation Strategy which we love).

          So we are currently are forced to make agent users into Jenkins Admins, which undermines Slave to Master controls.

          *The Feature*

          We would like to add a new configuration, {{agentUserNames}}.

          This would behave in the same way as {{adminUserNames}} does now ([example|https://github.com/jenkinsci/github-oauth-plugin/blob/master/src/main/java/org/jenkinsci/plugins/GithubRequireOrganizationMembershipACL.java#L92]), however only for Agent/* permission checks.

          This means that any usernames declared in the {{agentUserNames}} will short-circuit the ACL checking function if it is for an {{Agent/*}} permission.

          *A Question*

          As this is currently blocking us, we are planning to implement the above feature in a fork of this plugin. We wanted to ask early on, whether it sounds like an OK solution and something we could contribute via a PR when we are done?

           
          Andreas Nygard made changes -
          Description Original: *Background*

          We are operating Jenkins in an enterprise where we have [Slave to Master control|https://wiki.jenkins.io/display/JENKINS/Slave+To+Master+Access+Control] in place.

          Unfortunately this plugin doesn't allow mapping GitHub users to {{Agent/*}} permissions (aside from matrix auth, but that causes us to lose Committer Authorisation Strategy which we love).

          So we are currently are forced to make agent users into Jenkins Admins, which undermines Slave to Master controls.

          *The Feature*

          We would like to add a new configuration, {{agentUserNames}}.

          This would behave in the same way as {{adminUserNames}} does now ([example|https://github.com/jenkinsci/github-oauth-plugin/blob/master/src/main/java/org/jenkinsci/plugins/GithubRequireOrganizationMembershipACL.java#L92]), however only for Agent/* permission checks.

          This means that any usernames declared in the {{agentUserNames}} will short-circuit the ACL checking function if it is for an {{Agent/*}} permission.

          *A Question*

          As this is currently blocking us, we are planning to implement the above feature in a fork of this plugin. We wanted to ask early on, whether it sounds like an OK solution and something we could contribute via a PR when we are done?

           
          New: *Background*

          We are operating Jenkins in an enterprise where we have [Slave to Master control|https://wiki.jenkins.io/display/JENKINS/Slave+To+Master+Access+Control] in place.

          Unfortunately this plugin doesn't allow mapping GitHub users to {{Agent/*}} permissions (aside from matrix auth, but that causes us to lose Committer Authorisation Strategy which we love).

          So we are currently are forced to make agent users into Jenkins Admins, which undermines Slave to Master controls.

          *The Feature*

          We would like to add a new configuration, {{agentUserNames}}.

          This would behave in the same way as {{adminUserNames}} does now ([example|https://github.com/jenkinsci/github-oauth-plugin/blob/master/src/main/java/org/jenkinsci/plugins/GithubRequireOrganizationMembershipACL.java#L92]), however only for Agent/* permission checks.

          This means that any usernames declared in {{agentUserNames}} will short-circuit the ACL checking function if it is for an {{Agent/*}} permission.

          *A Question*

          As this is currently blocking us, we are planning to implement the above feature in a fork of this plugin. We wanted to ask early on, whether it sounds like an OK solution and something we could contribute via a PR when we are done?

           
          Sam Gleske made changes -
          Link New: This issue duplicates JENKINS-27844 [ JENKINS-27844 ]
          Andreas Nygard made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]
          Andreas Nygard made changes -
          Assignee Original: Sam Gleske [ sag47 ] New: Andreas Nygard [ nygardan ]
          Andreas Nygard made changes -
          Attachment New: image-2021-07-01-10-20-00-593.png [ 55092 ]
          Andreas Nygard made changes -
          Attachment New: image-2021-07-01-10-20-42-544.png [ 55093 ]

            nygardan Andreas Nygard
            nygardan Andreas Nygard
            Votes:
            1 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: