I'm logged in as my user account (an admin) in Jenkins. I have project-based security on, with no access to "anonymous" user. Now when I run my Jenkins jobs manually, or via cron, the jobs run as "anonymous" user. How can I set my jobs to run as "jenkins" user by default?
Note I read Run jenkins job as another user, and the the default user is /etc/default/jenkins is jenkins, and that user owns the Jenkins files.
I mean why are my jobs "Running as anonymous" (seen on a job's console session) when I run them as my user, an admin user, or triggered by a timer?
I found it.
In Manage Jenkins -> Configure Global Security, toward the middle of page there's a section called Access Control For Builds. The Strategy was set to Run as anonymous, I set it to Run as SYSTEM.
Related
I have Jenkins CI/CD dry run job that each developer can trigger. The question is, can each developer have permissions to stop/abort only his flows which he triggered or Jenkins doesn't support it?
The lowest level of authorization is project-based security via the Matrix Authorization Strategy plugin with Job: Build/Cancel and Run: Delete/Replay/Update.
You could use the build user vars plugin together with the Build Name and Description Setter plugin to add the ${BUILD_USER} to the build's name and/or description (with ☑️ Set build name before build starts) so that each dev knows which build to abort in case.
See also How to get the BUILD_USER in Jenkins when job triggered by timer?.
To restrict the build history to the currently logged on user set the build name to #$BUILD_NUMBER - Started by $BUILD_USER and see my user script Jenkins - Restrict build history to current user:
Jenkins cluster in my company runs builds as root user.
How to configure cluster/build to run as a different user? Without root privileges ?
Builds always run under the user that runs the node agent process. So your options are
Specify a different user for connecting the node, or
Switch to a different user during the build (e.g., via sudo in a shell build step). This is more flexible, but plugin related-code (like SCM checkout) will still run under the root account.
Any agent can be configured to be launched as any user, so do that.
Advise your company Jenkins Admin to change Jenkins immediately to NOT run as root. It does not need root (can be a daemon/service tho) and increases your risk exposure . We use Java Service Wrapper (RUN_AS_USER=jenkins) in Unix. The new windows installer prompts you for the account to use (don't use System despite being the default).
I am trying to create a new directory and copy files to it. So I'm using a job of "Execute batch command".
First I tried to run: robocopy source destination /e.
Then I tried: mkdir destination. In both cases I got an "Access is denied" mssage.
If I try it myself manualy I am able to create a directory and copy files to it.
The destination is a remote computer's shared folder: \computerName\sharedFolder\
Anyone knows how to get access rights with Jenkins?
I know this post is a bit old but I found two solutions that work pretty well so I'm posting it in case somebody needs it.
First: allowing the disk usage for the current run
On your "Execute batch command" you can add a line:
net use \\server\folder /USER:domain\user password
You can then use \server\folder in your commands and it'll work.
Jenkins can even deal with credentials so that there's not in plain text.
The second solution is to boot Jenkins as a specific user so that all the commands will be run as this user.
To do this:
Open services app in windows
Search for Jenkins
Right click, properties
On Log On tab configure the credentials you want to use
Reboot Jenkins
I hope this helps someone
To find out the user under which your jobs run, create a "scratch" job in Jenkins. Give it a single "Execute Windows Batch command" build step and enter "set" as the text of your batch command. If your affected job is running on a Windows slave, make sure this job runs on the same slave. Run the job. Your console will show a list of the environment variables known to that job, the same as if you typed "set" in a Command Prompt window on your desktop. The difference will be that near the bottom, the username shown for "USERDOMAIN" and "USERNAME" in your command window will be you (the user you are logged in as); in the console output, it will be the user account that your Jenkins job runs under.
That user may not actually have login rights. And, if Jenkins is running as a service, you can't just set up a share in your command window: Jenkins jobs run under a different Windows "session" and that session will not see the share you created in your login session.
A not-very-secure way to get you over the hump would be to add parameters to your job for the username (string parameter) and password (password parameter). Before you need access to the drive, either in the same build step or in a 'Execute Windows Batch Command' step that runs prior to that build step, run "#net use : \computername\sharename %% /USER:%% /persistent:no". (for example: "#net use p: \COMPUTER\SHARE %PASSWORD% %USER% /persistent:no"). The "#" will keep the password from showing in the log. (However, the password will be associated with the job and will be encoded in Jenkins if "Allow rebuild" is enabled.) Make sure when you are done you clean up ("net use /delete") and you may need to test and clean up the drive letter before you try to connect, in case a previous job failed without releasing the drive letter.
In this scenario you would have to enter a username and password for someone who can access the share when you run the job. You could encode hidden parameters with these values pre-filled in, but that means that user's username and password are encoded into the job definition, and the default for the hidden password parameter would not be encrypted in the Jenkins config files.
There are definitely more secure ways to get the drive share enabled in the Jenkins service session, but depending on your environment this may be 'good enough' to get you past the block you are faced with right now. I have used tricks like these in an environment where I was not a Jenkins administrator and I had very limited access rights (and no admin rights) on the Jenkins slaves.
In my setup, the Jenkins slave service runs under a specific user (named jenkins).
It makes it easy to verify the access rights for that specific user.
Of course jenkins needs to have write access on the remote folder, both on the physical disk and the share.
I have a jenkins setup with multiple users which are logging in with Active Directory plugin. This is useful so that each user can access his own tasks.
However each user also has different permissions on the local network, such as access to different folders etc. I have noticed that the permissions given to each task is not linked to the user but to the account under which the slave is running as service. Is there a way to change that so that the task is executed on the slave under the credential (and hence permissions) of the user?
Thank you
The problem is: there is only one slave process running the different job assigned to that server by the Jenkins master.
So the slave itself runs as one user (generally, a dedicated account or a system account).
Since you can get the user id as environment variable (with a plugin like JENKINS Build User Vars Plugin), you might consider configuring the job in order for it build step to "run as" the user who triggered the build.
See for instance the JENKINS Authorize Project plugin.
However, as mentioned this answer:
The "Authorize Project" plugin does not change the OS level user that is running commands.
It only sets the Jenkins user that is running the job and any downstream jobs, using Jenkins authentication (whatever it might be).
So you are left with build step with runas or su -c commands in order to be sure that your task does run with the right user.
I had the similar issue and I can recall for managing more control on projects I used role strategy plugin and setup global security using LDAP servers (Active directory should also be ok).
And I used authorized project plugin.
Have a look and I hope it should solve your purpose. Let me know on comment section for any clarification.
you can partially fix your problem this way:
install the slave as a service using the Java Web Start method and JLNP
go to Services control panel in windows
under Properties -> Connection replace the local system connection with a specific user
rebooted the service
This at least gives you the ability to use one account instead of system.
I have a problem figuring out how I can add credentials for a deploy job in gitlab in a way that only a certain user or usergroup gets access to them.
So what I want to do is the following. I have a gitlab instance with a gitlab-ci configuration that adds a manually activated job to deploy my code. The deploy job runs in a docker image and deploys via fabric to a server. This fabric call now needs an ssh private key to log into the server to deploy onto. That still wouldn't prevent anyone from clicking on this manual job but at least it would fail because of the missing credentials.
I now added the ssh private key as a secret variable. But unfortunately, this secret variable is visible to everyone who can trigger the build. Which would be all developers. Because I, of course, want them to be able to trigger the build jobs. I just don't want them to be able to trigger the deploy job. And I, of course, don't want them to be able to access the ssh key. E.g. through checking in "echo $SECRET_VARIBLE". So in my ideal world, I would be able to add a secret variable only to my account with is only set if I am the person who triggers the job.