Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-63421

Agent/Connect and other Agent permissions

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      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?

       

        Attachments

          Issue Links

            Activity

            Hide
            sag47 Sam Gleske added a comment - - edited

            JENKINS-27844 outlines the planned rewrite of repository permissions.

            I would like it to be a cross between project matrix auth and the committer authorization strategy which allows one to arbitrarily choose any permission depending on the user's role in the repository.

            Show
            sag47 Sam Gleske added a comment - - edited JENKINS-27844 outlines the planned rewrite of repository permissions. I would like it to be a cross between project matrix auth and the committer authorization strategy which allows one to arbitrarily choose any permission depending on the user's role in the repository.
            Hide
            nygardan Andreas Nygard added a comment - - edited

            Hi Sam Gleske, so if I play back my understanding, the idea is:

            • Extend the existing Github committer strategy to support opt-in Matrix-based permissions
              • It will behave exactly the same as Github committer strategy does today if no matrix-auth permissions are configured (since matrix auth will be opt-in), keeping this feature backward compatible
              • By extending the existing strategy, we provide less choices to the user and so keep the UX simple
            • If the opt-in Matrix-based or Project Matrix-based permissions are used, they are additive
              • This keeps behaviour consistent with the additive-approach taken in the Matrix Authorization plugin

            Are you aware of any work that has been undertaken or underway on this, in order for my team to leverage existing bits?

            Cheers

            Show
            nygardan Andreas Nygard added a comment - - edited Hi Sam Gleske , so if I play back my understanding, the idea is: Extend the existing Github committer strategy to support opt-in Matrix-based permissions It will behave exactly the same as Github committer strategy does today if no matrix-auth permissions are configured (since matrix auth will be opt-in), keeping this feature backward compatible By extending the existing strategy, we provide less choices to the user and so keep the UX simple If the opt-in Matrix-based or Project Matrix-based permissions are used, they are additive This keeps behaviour consistent with the additive-approach taken in the Matrix Authorization plugin Are you aware of any work that has been undertaken or underway on this, in order for my team to leverage existing bits? Cheers
            Hide
            sag47 Sam Gleske added a comment - - edited

            No work has been done beyond brainstorming as far as I'm aware.

            • They are not additive.  It would replace the existing system but functionally work the same.
            • The configuration for upgrading Jenkins infra would be migrated in a way that permissions are preserved.
            • The default permissions on a new Jenkins instance (configured in  matrix-like style) should be  the same as it always has been.
            • The intent is to  extend support for all permissions dynamically because different plugins can provide their own custom permissions (e.g. extended read plugin).
            Show
            sag47 Sam Gleske added a comment - - edited No work has been done beyond brainstorming as far as I'm aware. They are not additive.  It would replace the existing system but functionally work the same. The configuration for upgrading Jenkins infra would be migrated in a way that permissions are preserved. The default permissions on a new Jenkins instance (configured in  matrix-like style) should be  the same as it always has been. The intent is to  extend support for all permissions dynamically because different plugins can provide their own custom permissions (e.g. extended read plugin).

              People

              Assignee:
              sag47 Sam Gleske
              Reporter:
              nygardan Andreas Nygard
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated: