[JENKINS-58902] Non-user-scoped credentials are not shown when build authentication is configured

[nfalco79]

Fix CredentialProvider to always gather system credentials when logged user or user associated to run the project by Authrize Project plugin have USE_ITEM permission. This allow a user/admin/devops to create a project and configure it choosing credentialsId between one of possible. Actually no one system credentials is shown also if current and the use selected in Authorize Project plugin have JOB/configure permission.

I did not have change SystemCredentialProvider because in the signature we have only ItemGroup for which is not possible get ACL and query if given authorisation has USE_ITEM permission. This issue happens only on UI because at runtime CredentialsProvider.findCredentialById has already the logic to lookup peeking in mind USE_ITEM/USER_OWN permission when current authentication is not ACL.SYSTEM

• [x] Make sure you are opening from a feature branch (right side) and not your main branch!
• [x] Ensure that the pull request title represents the desired changelog entry
• [x] Please describe what you did
• [x] Link to relevant issues in GitHub or Jira
• [ ] Link to relevant pull requests, esp. upstream and downstream changes
• [ ] Ensure you have provided tests - that demonstrates feature works or fixes the issue

[nfalco79]

@jglick If you agree on approach I can provide some test case. This bug is there since a couple of year and we survive till now just because we use 90% pipeline libraries and old projects we never change credentialsId so at runtime it use defined. But it's a headache every time DevOps have to setup a project where UI propose to choose credentials or when we save current project where credentials selection is --current--

[jglick]

I am afraid I know next to nothing about user-scoped credentials and cannot meaningfully review this. Generally think it best to avoid them.

Also see #210.

[nfalco79]

I saw that PR but here is more about delegating to scope SYSTEM when current user has job configuration permission. I mean the actual behaviour is if I can configure a job I'm not able to see any credentials at all (except my personal). Who is the best person to review this PR. This bug is there since 2 years and also impact other plugin. In JIRA follow the linked issues (artifactory plugin also)

[jglick]

Who is the best person to review this PR.

I am afraid I do not know who has expertise. @jvz? Original creator of user credentials was @stephenc but this is something about usage with authorize-project (which last I recall was abandoned).

[nfalco79]

authorize-project is free for adoption (maybe for you mean abandoned) but since Jenkins warning you to use at least one QueueItemAuthenticator implementation and there are not much choice... this have to work otherwise the only work around is run jobs with SYSTEM rights, because all other options (pre defined user, user that trigger the build and anonymous) does not work. The point is that I got the issue and I'm administrator. At runtime it works because credentials are resolved taking into account these cases.

[jglick]

Not currently comfortable merging any PRs related to user credentials since I do not understand the security model.

[nfalco79]

rebase master. There are other 3/4 bugs related to this defect. @jvz could you have a look into this please?

[nfalco79]

@jtnord please provide some details on how to should be changed the code in the PR to solve all issues related to the current behaviour

[jtnord]

@jtnord please provide some details on how to should be changed the code in the PR to solve all issues related to the current behaviour

I do not think you can (and more to the point should) as System credentials must never be able to be used by anything other than System. if you run your jobs as a user - that includes those jobs.

perhaps start with a discussion on the Jenkins mailing list and / or a Jira ticket. but accessing System scoped credentials as anything other than System is a non starter for security reasons.

[nfalco79]

The issue is described step by step by @ikedam in JIRA. In my case I'm a Jenkins administrator, when i create new pipeline job and go to configure the SCM of kind Git, in the credentials combobox I can not see anything. If I run a build (policy "run as specific user") it works but THE problem is that I'm not able to configure any credentials using web UI. As workaround I have to edit the config.xml of the job in jenkins master and than reload the job (very bad practices).

[jglick]

since Jenkins warning you to use at least one QueueItemAuthenticator implementation

Not as of https://github.com/jenkinsci/jenkins/pull/6222.

[jvz]

Yo what up? It appears I don't get notifications from GitHub anymore (probably due to volume).

I'll note that one of the points of user scoped credentials are to separate them from the rest of the system such that they require some level of informed user consent to use said credentials anywhere. If I were to update the design of them today, I'd give each credential an ACL to allow others to use the credential, but that wouldn't really fit too well with the existing API as it's not directly tied to ACLs or any particular authorization model. However, I would generally expect that running a build as a user means having access to said user's credentials (consider it analogous to the RunAsManager in Spring Security where you should be granted all the same authorities as the user, hence that should imply access to their user-scoped secrets). I'm not familiar with how authorize-project works, though.

[jvz]

And system credentials aren't meant to be used by users; they're for the Jenkins system itself (background tasks such as scanning git repos). User scope and system scope should not cross beams as they're entirely unrelated scopes.

[LevN0]

@jvz

I am not sure if there is a miscommunication in this discussion.

Currently when using the "Authorize Project" plugin, and "Run as Specific User" is selected, "Global" scoped credentials under the "System" credential store are unavailable in the UI even when the user in "Run as Specific User" has the global Credentials/UseItem permission. These credentials can still be used in the job, as long as the global "Credentials/UseItem" is given, but they won't appear in the UI. This seems like a bug?

It should not be a security issue to add these into the UI, unless there is already a security issue given that these credentials can already currently be used by the job, they just don't show up in the UI.

The documentation states "Using the GLOBAL scope will, in addition to the usage permitted by SYSTEM scope, will make the credential available to all jobs within Jenkins running as an authentication that has the Credentials/UseItem permission."

The behavior of the job itself follows that, but the behavior of the UI does not.

[LevN0]

Looking at this further, JENKINS-58902 and JENKINS-55624 were about the Git plugin. It was the behavior of this plugin I was describing in my last comment, where when using the "Authorize Project" plugin, and "Run as Specific User" is selected, "Global" scoped credentials under the "System" credential store are unavailable in the UI but can be used on clone if the user for "Run as Specific User" has the global Credentials/UseItem permission..

I looked the credentials binding plugin too. This plugin also makes the "Global" scoped credentials under the "System" credential store available, if the user for "Run as Specific User" has the global Credentials/UseItem permission.

For the Git plugin, these lines of code are part of the problem together with how the Credentials plugin works. They use the user's authorization to populate the dropdown in the UI, but the Credentials plugin's SystemCredentialsProvider.getCredentials methods always reject anything other than ACL.SYSTEM.

I am not sure whether the change should belong in the Credentials plugin or the Git plugin, but parts of at least two common plugins seem to believe that "Global" scoped credentials in the "System" store should be accessible to all users with Credentials/UseItem permission. The documentation I quoted above also suggests that.

[Kevin-CB]

I agree with the previous comment, the current behavior is a bug. Global scoped credentials in the System store should be accessible to all users with the Credentials/UseItem permission.

It matches what is present in the documentation:

If you install the Authorize Project plugin and configure a job to run as a specific user, the credentials available to that job will now be determined by that user’s permissions in the context of that job. If the user does not have either Credentials/UseOwn (normally implied by Item/Build) or Credentials/UseItem (normally implied by Job/Configure) then the job will be unable to access any credentials at all. If a user has Credentials/UseOwn permission in a specific context then they are allowed to use their user scoped credentials for actions performed with their authentication in that context. For example, jobs running as the user’s authentication will have access to that user’s user scoped credentials if and only if the user has Credentials/UseOwn permission in the context of that job. If a user has Credentials/UseItem permissions in a specific context then they are allowed to use the global scoped credentials for actions performed with their authentication in that context. For example, jobs running as the user’s authentication will have access to the global scoped credentials available in the context of that job if and only if the user has Credentials/UseItem in the context of that job.

I think the current PR is correctly fixing it but should also check for the Credentials/UseOwn permission to permit user scoped credentials to be visible (the same code but not on ACL.SYSTEM but on the current authentication).

If you're still willing to update this PR, I'd be happy to test it and approve it to finally correct this bug!

[nfalco79]

I do not know what happens but the only way to update this PR is edit the source branch. Push on my repository does not trigger a build or update the content of this PR