-
Bug
-
Resolution: Won't Fix
-
Major
-
None
Environment
- Jenkins 2.46.2
- credentials:2.1.13 'Credentials Plugin'
- credentials-binding:1.11 'Credentials Binding Plugin'
- workflow-aggregator:2.5 'Pipeline'
- workflow-api:2.12 'Pipeline: API'
- workflow-basic-steps:2.4 'Pipeline: Basic Steps'
- workflow-cps:2.29 'Pipeline: Groovy'
- workflow-cps-checkpoint:2.4 'CloudBees Pipeline: Groovy Checkpoint Plugin'
- workflow-cps-global-lib:2.7 'Pipeline: Shared Groovy Libraries'
- workflow-durable-task-step:2.10 'Pipeline: Nodes and Processes'
- workflow-job:2.10 'Pipeline: Job'
- workflow-multibranch:2.14 'Pipeline: Multibranch'
- workflow-scm-step:2.4 'Pipeline: SCM Step'
- workflow-step-api:2.9 'Pipeline: Step API'
- workflow-support:2.14 'Pipeline: Supporting APIs'
Scenario to Use User Scoped Credentials in "withCredentials()"
Many organizations use GPG signing keys and special permissions on Git / Nexus / Artifactory to create releases. For traceability and security, these privileged credentials credentials are "per individual/personal credentials", they are not shared with team members.
For this kind of credentials, we want to use Jenkins User Scoped Credentials in pipeline (withCredentials, git, config-file-provider, ssh-agent...)
Description
- Even when using the authorize project plugin, user Scoped Credentials don't appear in the drop down lists of credentials.
- User scoped credentials don't appear in the drop down lists of credentials of the "Config File Provider Plugin" (problem not covered by this jira issue, I'll work on it later)
Reproduce
- Install the Project Authorize Plugin and configure it "Run as user who triggered the build"
- Create user scoped credentials "my-username-password"
- Create a pipeline
- Use the pipeline syntax assistant to generate a "withCredentials" wrapper
- The drop down list of credentials don't display the user scoped credentials "my-username-password"
- is related to
-
-
- Open
-
-
-
- Closed
-
-
JENKINS-47864 Allow to select User Scope Credentials
-
- Resolved
-
- relates to
-
-
- Resolved
-
-
JENKINS-58170 Allow credential parameters to shadow credential ids in lookup
-
- Resolved
-
- links to
[JENKINS-44774] User Scoped credentials don't appear in credentials drop down lists
FYI the reasoning why xjg6yzl feels it's a "blocker" are also detailed on
- https://issues.jenkins-ci.org/browse/JENKINS-44772?focusedCommentId=302524&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-302524
- https://issues.jenkins-ci.org/browse/JENKINS-44773?focusedCommentId=302534&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-302534
xjg6yzl I changed the priority of this issue to "major" for the moment. I'll let the community discussion help us define how important it is. I share your opinion that it's a very important feature but I don't want to interfere with the thought process of the community 
John Zerbe
added a comment - cleclerc, Thank you for this change in in priority. To reiterate, we have auditing requirements to show exactly who did every single push to our git repositories. We currently do this via more traditional Jenkins maven type jobs and maven steps in freeform jobs where we use the maven release plugin combined with user scoped credentials to allow maven to create the tags and update the version via an individual's credentials picked at build time. We do set security at the folder level for teams, but using credentials at the folder scope does not meet our requirements.
John Zerbe
added a comment - cleclerc , Thank you for this change in in priority. To reiterate, we have auditing requirements to show exactly who did every single push to our git repositories. We currently do this via more traditional Jenkins maven type jobs and maven steps in freeform jobs where we use the maven release plugin combined with user scoped credentials to allow maven to create the tags and update the version via an individual's credentials picked at build time. We do set security at the folder level for teams, but using credentials at the folder scope does not meet our requirements. Ignoring
- User scoped credentials don't appear in the drop down lists of credentials of the "Config File Provider Plugin"
which is not part of the steps to reproduce. Typo?
jglick The config file provider plugin is not part of this issue but I'll check it soon after. The use case that xjg6yzl has reported on the thread of this issue with a MAven Release is the same use case where you want to use your own credentials in a Maven build that runs on Jenkins.
When it is "Run as user who triggered the build" then we cannot know what the user will be, hence we cannot know which store to look for credentials in.
As I Understand It, if you configure with "Run as specific user" then that user's credentials will be present in the drop-down. If that is the case then this is Functioning as designed.
https://github.com/jenkinsci/git-plugin/commit/ffc9b9f24aec4a7965eaff572a985afcacde178a#diff-fedc76bc24b9680397327f85dccd1cd7R92 is following the correct patterns documented in https://github.com/jenkinsci/credentials-plugin/blob/master/docs/consumer.adoc#listing-available-credentials-matching-some-specific-set-of-criteria
The authorize project plugin will return the fall-back authentication when invoked via getDefaultAuthenticationOf(job) https://github.com/jenkinsci/authorize-project-plugin/blob/master/src/main/java/org/jenkinsci/plugins/authorizeproject/strategy/TriggeringUsersAuthorizationStrategy.java#L68
> When it is "Run as user who triggered the build" then we cannot know what the user will be, hence we cannot know which store to look for credentials in.
We could display the user-scoped credentials in the drop down with an indication saying that these credentials are tied to the user and may not be accessible at build time if another user triggers the build or trigger the phase (pipeline phase blocked by an input step).
This can be implemented via JENKINS-58170. It's already supported by build parameters, and we'll have full support for the same as an input step as well once that's released in JENKINS-47699.
This feature is implemented by JENKINS-58170 using a slightly different approach to that described in this ticket. The linked approach works using credentials build parameters which allows for using user-scoped credentials.
should be "blocker"