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

GitHub App to support credentials with multiple organizations

      We are trying to use same app on Jobs across orgs and is not working as we need to maintain duplicate credentials for multiple organization.

      Maintaining same credentials for multiple orgs seems duplicate to me, is there any chance we can avoid this?

      Our use case is, since it is internal (GitHub Enterprise) bot, it is pretty open and we don't even know who would invite this bot to their organization, and this bot does takes care of creating Jenkins job through DSL scripts, which is using the standard credentials. So it is very hard to keep creating credentials on the fly for every org that this bot is being invited to.

      Thanks a bunch for all the help on maintaining this awesome plugin. Let me know your thoughts please.

      Related discussion on PR: https://github.com/jenkinsci/github-branch-source-plugin/pull/290#discussion_r415168275

          [JENKINS-62220] GitHub App to support credentials with multiple organizations

          Hutson Betts added a comment -

          My company uses Jenkins in a similar fashion as the company described by nrayapati

          We deployed a single Jenkins GitHub App, which may be installed by any organization on our GHE instance. There are several hundred such organizations.

          We allow our engineers to create jobs as needed within their own Jenkins folders while leveraging the single/shared GitHub App Credential.

          Since any engineer can install our GitHub App on their organization, and any engineer can create an organization, we would be in the situation of needing to create a Credential for every organization as it's created.

          Therefore, I too would like to see support for a single global Credential to work for jobs across multiple organizations.

          Hutson Betts added a comment - My company uses Jenkins in a similar fashion as the company described by nrayapati We deployed a single Jenkins GitHub App, which may be installed by any organization on our GHE instance. There are several hundred such organizations. We allow our engineers to create jobs as needed within their own Jenkins folders while leveraging the single/shared GitHub App Credential. Since any engineer can install our GitHub App on their organization, and any engineer can create an organization, we would be in the situation of needing to create a Credential for every organization as it's created. Therefore, I too would like to see support for a single global Credential to work for jobs across multiple organizations.

          Leo Quote added a comment -

          I think we can get org name from repo configure instead of credential config , that will fix this.

          Leo Quote added a comment - I think we can get org name from repo configure instead of credential config , that will fix this.

          We have the exact same situation and now running into problems, since the Jenkins Master is delivered by us with a "built-in" GitHub App Credential to be used against the GitHub Enterprise. The problem can be bypassed when making the repository public, which is not intended for all repositories.

          I think the the following issue is related: https://issues.jenkins-ci.org/browse/JENKINS-62594

          Sergei Waigant added a comment - We have the exact same situation and now running into problems, since the Jenkins Master is delivered by us with a "built-in" GitHub App Credential to be used against the GitHub Enterprise. The problem can be bypassed when making the repository public, which is not intended for all repositories. I think the the following issue is related:  https://issues.jenkins-ci.org/browse/JENKINS-62594

          Dee Kryvenko added a comment - - edited

          To add more context, this isn't just a GHE but a GitHub.com issue as well. From the discussion in that PR:

           I presume the common case is for the Jenkins installation to be used on only a single org.

          That assumption was very, very uninformed to say the least. The whole purpose of the GitHub Apps is so that users/orgs can install the Apps dynamically and it wouldn't require to reconfigure backend system that is behind the App - the backend system should be able to discover who is using it and automatically start catering for a new user/org. The key principle behind GitHub Orgs Folders is automatic repositories discoverability, and initial implementation for GitHub App credentials seems to be contradicting to this principle. Of course, as mentioned in another comment on that PR - it is better than nothing. I understand there is certain complexity associated with implementing this feature and I am not criticizing and I am grateful so that we have this feature at all, even with this limitation. I am merely trying to draw attention and demonstrate significance/importance of this request. Having hundreds of orgs installed a single App is a valid and I would imagine pretty common use case.

          Dee Kryvenko added a comment - - edited To add more context, this isn't just a GHE but a GitHub.com issue as well. From the discussion in that PR :  I presume the common case is for the Jenkins installation to be used on only a single org. That assumption was very, very uninformed to say the least. The whole purpose of the GitHub Apps is so that users/orgs can install the Apps dynamically and it wouldn't require to reconfigure backend system that is behind the App - the backend system should be able to discover who is using it and automatically start catering for a new user/org. The key principle behind GitHub Orgs Folders is automatic repositories discoverability, and initial implementation for GitHub App credentials seems to be contradicting to this principle. Of course, as mentioned in another comment on that PR - it is better than nothing. I understand there is certain complexity associated with implementing this feature and I am not criticizing and I am grateful so that we have this feature at all, even with this limitation. I am merely trying to draw attention and demonstrate significance/importance of this request. Having hundreds of orgs installed a single App is a valid and I would imagine pretty common use case.

          Dileep Reddy added a comment -

          This is really a problem. We have to configure multiple credentials for multiple organizations. And everytime, we install on a new org, we need to make sure its credentials are created too.

          This is a problem especially with plugins that need app-only creds (e.g: github-checks plugin).

          Is there a workaround for this?

          Dileep Reddy added a comment - This is really a problem. We have to configure multiple credentials for multiple organizations. And everytime, we install on a new org, we need to make sure its credentials are created too. This is a problem especially with plugins that need app-only creds (e.g: github-checks plugin). Is there a workaround for this?

          Created https://issues.jenkins.io/browse/JENKINS-64662 to support owner override through withCredentails to support other use pipeline use cases.

          Naresh Rayapati added a comment - Created https://issues.jenkins.io/browse/JENKINS-64662  to support owner override through withCredentails to support other use pipeline use cases.

          Dee Kryvenko added a comment -

          I just thought of another issue related to this. Consider a pipeline that needs access to more than one org simultaneously. It might be a Go module or a Terraform module that reaching out for dependencies - nothing fancy, totally legit use case. Pipeline is not aware of what the underlying tool will try to reach, but as long as the GitHub App is authorized in all of the orgs - it should be possible to do that.
          My understanding is it's currently not and it's probably on GitHub side? What's the alternative, deprecating services and etc - it seems like GitHub Apps are the only recommended one auth type?

          Dee Kryvenko added a comment - I just thought of another issue related to this. Consider a pipeline that needs access to more than one org simultaneously. It might be a Go module or a Terraform module that reaching out for dependencies - nothing fancy, totally legit use case. Pipeline is not aware of what the underlying tool will try to reach, but as long as the GitHub App is authorized in all of the orgs - it should be possible to do that. My understanding is it's currently not and it's probably on GitHub side? What's the alternative, deprecating services and etc - it seems like GitHub Apps are the only recommended one auth type?

          Naresh Rayapati added a comment - - edited

          Looks like currently GitHubAppCredentials is using app installation token, not sure of the actual/initial design notes, probably if we convert it to use the JWToken to avoid the issue reported in this JIRA. 

          Logged a new Jira for that:
          https://issues.jenkins.io/browse/JENKINS-64870 

          JWT Token vs App Installation Token
          https://github-api.kohsuke.org/githubappjwtauth.html
          https://github-api.kohsuke.org/githubappappinsttokenauth.html

          Naresh Rayapati added a comment - - edited Looks like currently GitHubAppCredentials is using app installation token, not sure of the actual/initial design notes, probably if we convert it to use the JWToken to avoid the issue reported in this JIRA.  Logged a new Jira for that: https://issues.jenkins.io/browse/JENKINS-64870   JWT Token vs App Installation Token https://github-api.kohsuke.org/githubappjwtauth.html https://github-api.kohsuke.org/githubappappinsttokenauth.html

          Dee Kryvenko added a comment -

          I'm pretty sure we need support for both. Certain use cases will need it exactly the way it is currently implemented. Consider a case with 3 independent parties - end users of jenkins (owners of orgs/repos), app owner (owner of jenkins installation) and github. In certain scenarios you will want to use same GitHub app to authenticate Jenkins installation but still prevent different Jenkins end-users via their pipelines to be able to meddle with each other.

          Dee Kryvenko added a comment - I'm pretty sure we need support for both. Certain use cases will need it exactly the way it is currently implemented. Consider a case with 3 independent parties - end users of jenkins (owners of orgs/repos), app owner (owner of jenkins installation) and github. In certain scenarios you will want to use same GitHub app to authenticate Jenkins installation but still prevent different Jenkins end-users via their pipelines to be able to meddle with each other.

          I have started a draft PR to github-api so one app can handle multiple tokens based on the org from the URL that it is trying to access
          https://github.com/hub4j/github-api/pull/1053

          Carlos Sanchez added a comment - I have started a draft PR to github-api so one app can handle multiple tokens based on the org from the URL that it is trying to access https://github.com/hub4j/github-api/pull/1053

          Liam Newman added a comment -

          My understanding is that you can only use JWT tokens for a limited set of GitHub endpoints. See https://docs.github.com/en/rest/reference/apps

          Aside from those, you'll need an App Installation token.

          csanchez
          Guessing the org based on the URL that is being accessed seems extremely brittle to me. What is the use case where one GitHub instance (and it's related authorization provider) would need to apply to multiple organizations? At the github-api level, creating new GitHub instance for each org is not a big deal. T

          This sounds like a problem best solved at Jenkins level. It is totally reasonable to add github-api methods to make this work easier, but I think they're already there.

          Liam Newman added a comment - My understanding is that you can only use JWT tokens for a limited set of GitHub endpoints. See https://docs.github.com/en/rest/reference/apps Aside from those, you'll need an App Installation token. csanchez Guessing the org based on the URL that is being accessed seems extremely brittle to me. What is the use case where one GitHub instance (and it's related authorization provider) would need to apply to multiple organizations? At the github-api level, creating new GitHub instance for each org is not a big deal. T This sounds like a problem best solved at Jenkins level. It is totally reasonable to add github-api methods to make this work easier, but I think they're already there.

          Dee Kryvenko added a comment -

          bitwiseman you are right - all JWT is good for is basically to generate access tokens with limited scope.

          I think what nrayapati is doing in https://github.com/jenkinsci/github-branch-source-plugin/pull/374 makes the most sense. If only we can extend it to also supply repository_ids - that would also address a confused deputy attack vector I just reported here https://issues.jenkins.io/browse/JENKINS-66580.

          Dee Kryvenko added a comment - bitwiseman you are right - all JWT is good for is basically to generate access tokens with limited scope. I think what nrayapati is doing in https://github.com/jenkinsci/github-branch-source-plugin/pull/374 makes the most sense. If only we can extend it to also supply repository_ids - that would also address a confused deputy attack vector I just reported here https://issues.jenkins.io/browse/JENKINS-66580 .

          Jesse Glick added a comment -

          github-branch-source-plugin #527 may solve this for most cases; as yet untested.

          Jesse Glick added a comment - github-branch-source-plugin #527 may solve this for most cases; as yet untested.

          Jesse Glick added a comment -

          Also requires git-plugin #1242 if you wish to use the App token for multibranch credentials (the normal case).

          Jesse Glick added a comment - Also requires git-plugin #1242 if you wish to use the App token for multibranch credentials (the normal case).

          Mark Waite added a comment -

          Git plugin #1242 released in git plugin 4.11.0 March 26, 2022.

          Mark Waite added a comment - Git plugin #1242 released in git plugin 4.11.0 March 26, 2022.

            jglick Jesse Glick
            nrayapati Naresh Rayapati
            Votes:
            5 Vote for this issue
            Watchers:
            19 Start watching this issue

              Created:
              Updated:
              Resolved: