-
New Feature
-
Resolution: Unresolved
-
Major
-
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?
- duplicates
-
JENKINS-27844 Improve Use Github repository permissions
-
- Open
-
[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 ] |
Hi sag47, 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
Andreas Nygard
added a comment - - edited Hi sag47 , 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 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).
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).
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 
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.