I am currently setting up an automated deployment pipeline in Jenkins and I need to run a specific build job under a different user account for auditing and permission reasons. Right now, every job seems to run as the 'system' or 'jenkins' user by default. Is there a way to configure a job to execute with the identity of a specific person or service account, or perhaps trigger it using their API token so the build history shows they were the one who initiated the process?
3 answers
To run a job as a different user in Jenkins, the most robust method is using the "Authorize Project" plugin. Once installed, you can go to Manage Jenkins > Configure Global Security and set up "Strategy for project authorization." This allows you to define per-project whether a job should run as the user who triggered it or as a specific fixed user. This is crucial for Cyber Security and compliance, as it ensures that the job only has access to the resources that the specific user is permitted to use. Alternatively, if you are triggering jobs via a script, you can use that user's API Token in your CURL command. This ensures the Jenkins build history explicitly lists the user associated with that token as the "Started by" entity, providing a clear audit trail for your production changes.
That plugin approach seems perfect for UI-based triggers, but if I am using a Jenkinsfile in a declarative pipeline, can I specify a different user within the script itself? I want to make sure that the shell commands inside my pipeline stages are executed with specific restricted permissions rather than full master access.
If you just want to see a different name in the build history for a manual trigger, you can use the "Build User Vars" plugin. It captures the ID of the person who clicked the button.
I agree with Nancy. If your goal is just reporting and not actual permission enforcement, Build User Vars is much simpler to set up. It injects variables like BUILD_USER which you can then use in your notifications or Slack alerts to identify exactly who started the deployment.
Steven, for pipeline scripts, you typically handle this using the credentials() helper. While you can't easily change the "Jenkins user" mid-script for the audit log, you can wrap your commands in a block like withCredentials([usernamePassword(...)]). This allows you to log into external systems or databases as a specific user. For the Jenkins execution itself, the Authorize Project plugin remains the standard because it sets the security context for the entire run before the Groovy script even starts executing.