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).
            Hide
            jimklimov Jim Klimov added a comment - - edited

            Hello, as a user of Swarm plugin I am also interested in this subject - since if we enable Github Auth plugin for the team members, we seem to lose access for locally defined accounts that swarm clients log into Jenkins controller with.

            It seems clumsy to have do define account(s) for the swarm client(s) on github for dynamic connections from the internal build farm. I did not check yet if a dedicated set of github login + pass/token suffice for the swarm client on a worker (and if that works - probably such account should be outside the Github organization so it has no rights there and in Jenkins jobs by accident), or if it should also have to have access to the internet and hop to github login forms and back...

            Is it possible to (develop extensions to) mix "local database" accounts with Github ones, so we can have the benefits of both? This idea does seem compatible with proposal here, to allow Github auth strategy to set the Agent/* permissions to certain accounts (like the Matrix strategy can), with an extension that such accounts might not be defined in Github but rather locally.

            UPDATE: It was indeed possible to reconnect the swarm clients with a new github account not attached to any organization, after I generated a token for it with "read:user" (and "user:email") permissions, and also "read:org" seemed to be required - auth failed on a first token without it). Note that API auth directly by password no longer works on Github side since last year, only tokens. On an upside, this allows to issue (and pull back) many tokens for many build agents using the same account.

            On Jenkins side, I also had to switch from GitHub strategy to a manually made somewhat similar matrix (for our project's static list of GH organizations and accounts, though I am not sure the matrix setup can go into such detail as github-auth can - e.g. considering PR authors, collaborators, contributors... as special groups), and allowed that new account the permissions needed for Swarm client (Overall/Read and some of Agent/* ones). I was not able to authenticate the swarm client with an account defined only locally with a password, although this account is otherwise known and manageable in Jenkins UI.

            I have also double-checked that with the worker isolated by firewall so it can not access the Internet and can only talk to the Jenkins controller (in the same subnet), authentication still works - so it is not the client that has to go to github and back to confirm the account. Cool on that side

            Show
            jimklimov Jim Klimov added a comment - - edited Hello, as a user of Swarm plugin I am also interested in this subject - since if we enable Github Auth plugin for the team members, we seem to lose access for locally defined accounts that swarm clients log into Jenkins controller with. It seems clumsy to have do define account(s) for the swarm client(s) on github for dynamic connections from the internal build farm. I did not check yet if a dedicated set of github login + pass/token suffice for the swarm client on a worker (and if that works - probably such account should be outside the Github organization so it has no rights there and in Jenkins jobs by accident), or if it should also have to have access to the internet and hop to github login forms and back... Is it possible to (develop extensions to) mix "local database" accounts with Github ones, so we can have the benefits of both? This idea does seem compatible with proposal here, to allow Github auth strategy to set the Agent/* permissions to certain accounts (like the Matrix strategy can), with an extension that such accounts might not be defined in Github but rather locally. UPDATE: It was indeed possible to reconnect the swarm clients with a new github account not attached to any organization, after I generated a token for it with "read:user" (and "user:email") permissions, and also "read:org" seemed to be required - auth failed on a first token without it). Note that API auth directly by password no longer works on Github side since last year, only tokens. On an upside, this allows to issue (and pull back) many tokens for many build agents using the same account. On Jenkins side, I also had to switch from GitHub strategy to a manually made somewhat similar matrix (for our project's static list of GH organizations and accounts, though I am not sure the matrix setup can go into such detail as github-auth can - e.g. considering PR authors, collaborators, contributors... as special groups), and allowed that new account the permissions needed for Swarm client (Overall/Read and some of Agent/* ones). I was not able to authenticate the swarm client with an account defined only locally with a password, although this account is otherwise known and manageable in Jenkins UI. I have also double-checked that with the worker isolated by firewall so it can not access the Internet and can only talk to the Jenkins controller (in the same subnet), authentication still works - so it is not the client that has to go to github and back to confirm the account. Cool on that side
            Hide
            nygardan Andreas Nygard added a comment - - edited

            Hi Sam Gleske , we are picking up this story now after some delay. I'm updating you below on where we are at, and what our thinking is for the next step.

            Implementation challenges

            I made an attempt at implementing the hybrid solution ("if matrix role is defined for user, use that, else, use github derived role"). From an implementation perspective, I have not succeeded. It requires nesting the UI widgets of the 2 plugins:

            From a maintainability perspective, I would like to treat the above two widgets as black boxes. Our feature should just compose the underlying features.

            The correct approach appears to be to use jelly include in order to compose the page:

            • Matrix widget: <st:include page="config.jelly" class="hudson.security.GlobalMatrixAuthorizationStrategy" />
            • GH widget: <st:include page="config.jelly" class="org.jenkinsci.plugins.GithubAuthorizationStrategy" />

            However I receive a runtime exception when attempting to render the page using the above approaches (I don't have it on hand sorry, I have since moved to a new approach). I suspect that the jelly framework is not very great at encapsulating UI components to allow this kind of composition, and I'll be required to jump through hoops to plumb it all together.

            Rethinking the approach

            Let's come back to the original problem: this plugin has a security vulnerability. A malicious user could compromise the credential on an agent, and use it to become an admin on the master. This is because agent->master accounts currently require full admin. This is especially problematic in enterprise environments, where agents can be operated by other teams, so it is trivial for them to obtain the agent credential. Jenkins has made steps to address this with Slave to Master Access Control, but that approach is undermined by the flaw in this plugin.

            In order to make it easy for people to do the right thing, I feel that the original suggestion of adding a new configuration, agentUserNames, is the better approach. This is because it specifically addresses the security problem, in an opinionated way. The alternate suggestion of giving users a super-generic matrix-hybrid permission system also allows the problem to be solved, but it does not present the security flaw. Most users will probably keep doing what they are doing if we offer the hybrid solution.

            Therefore, I think the original suggestion is more pragmatic, solving the security flaw, and making it obvious to users that the flaw exists.

            TL;DR

            We are going with the original approach suggested in this ticket, since it is much easier to implement, and leads to better security outcomes for the community.

            Show
            nygardan Andreas Nygard added a comment - - edited Hi Sam Gleske , we are picking up this story now after some delay. I'm updating you below on where we are at, and what our thinking is for the next step. Implementation challenges I made an attempt at implementing the hybrid solution ("if matrix role is defined for user, use that, else, use github derived role"). From an implementation perspective, I have not succeeded. It requires nesting the UI widgets of the 2 plugins: https://github.com/jenkinsci/matrix-auth-plugin https://github.com/jenkinsci/github-oauth-plugin From a maintainability perspective, I would like to treat the above two widgets as black boxes. Our feature should just compose the underlying features. The correct approach appears to be to use jelly include in order to compose the page: Matrix widget: <st:include page="config.jelly" class="hudson.security.GlobalMatrixAuthorizationStrategy" /> GH widget: <st:include page="config.jelly" class="org.jenkinsci.plugins.GithubAuthorizationStrategy" /> However I receive a runtime exception when attempting to render the page using the above approaches (I don't have it on hand sorry, I have since moved to a new approach). I suspect that the jelly framework is not very great at encapsulating UI components to allow this kind of composition, and I'll be required to jump through hoops to plumb it all together. Rethinking the approach Let's come back to the original problem: this plugin has a security vulnerability. A malicious user could compromise the credential on an agent, and use it to become an admin on the master. This is because agent->master accounts currently require full admin. This is especially problematic in enterprise environments, where agents can be operated by other teams, so it is trivial for them to obtain the agent credential. Jenkins has made steps to address this with Slave to Master Access Control , but that approach is undermined by the flaw in this plugin. In order to make it easy for people to do the right thing , I feel that the original suggestion of adding a new configuration, agentUserNames , is the better approach. This is because it specifically addresses the security problem, in an opinionated way. The alternate suggestion of giving users a super-generic matrix-hybrid permission system also allows the problem to be solved, but it does not present the security flaw. Most users will probably keep doing what they are doing if we offer the hybrid solution. Therefore, I think the original suggestion is more pragmatic, solving the security flaw, and making it obvious to users that the flaw exists. TL;DR We are going with the original approach suggested in this ticket, since it is much easier to implement, and leads to better security outcomes for the community.
            Hide
            nygardan Andreas Nygard added a comment - - edited

            We have implemented the feature, which simply adds this new setting for reduced-permission agent accounts. Hope to raise a PR soon.

            Show
            nygardan Andreas Nygard added a comment - - edited We have implemented the feature, which simply adds this new setting for reduced-permission agent accounts. Hope to raise a PR soon.

              People

              Assignee:
              nygardan Andreas Nygard
              Reporter:
              nygardan Andreas Nygard
              Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated: