-
Notifications
You must be signed in to change notification settings - Fork 245
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[JENKINS-58902] Non-user-scoped credentials are not shown when build authentication is configured #274
base: master
Are you sure you want to change the base?
Conversation
@jglick If you agree on approach I can provide some test case. |
f4ac10d
to
1310df1
Compare
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. |
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). |
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. |
Not currently comfortable merging any PRs related to user credentials since I do not understand the security model. |
1310df1
to
4440aba
Compare
rebase master. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this goes against the security reasons for running as a user. when running as a user jobs should not have access to system credentials like this and introducing this behaviour would appear to be a security issue.
@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. |
The issue is described step by step by @ikedam in JIRA. |
Not as of jenkinsci/jenkins#6222. |
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 |
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. |
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. |
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 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. |
I agree with the previous comment, the current behavior is a bug. It matches what is present in the documentation:
I think the current PR is correctly fixing it but should also check for the If you're still willing to update this PR, I'd be happy to test it and approve it to finally correct this bug! |
…authentication is configured Fix CredentialProvider to gather system credentials when users have USE_ITEM USE_OWN permission.
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 |
04cd263
to
2daaf47
Compare
// also lookup credentials as SYSTEM if granted for this item | ||
if (authentication != ACL.SYSTEM2 | ||
&& (item.getACL().hasPermission2(authentication, CredentialsProvider.USE_ITEM) | ||
|| item.getACL().hasPermission2(authentication, CredentialsProvider.USE_OWN))) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I think I expressed myself incorrectly.
With only the CredentialsProvider.USE_OWN
permission, you should not be able to retrieve credentials with the SYSTEM
authentication. But it should be needed to retrieve the current user's credentials (with the user's authentication).
Meaning that the previous call on line 563 should check for this permission, similar to what is done in this code.
// also lookup credentials with scope SYSTEM when user has grants for this item | ||
if (authentication != ACL.SYSTEM2 | ||
&& (item.getACL().hasPermission2(authentication, CredentialsProvider.USE_ITEM) | ||
|| item.getACL().hasPermission2(authentication, CredentialsProvider.USE_OWN))) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto.
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