Handling Sudo Permissions in Jenkins Pipeline Agents: Best Practices and Guidance

Using Jenkins Ask a question
,
1

Hello Jenkins Community,

I don’t understand the recommended way to grant sudo permissions to an agent that executes pipeline steps requiring sudo access. Should I always provide the necessary permissions to specific steps using withCredentials function? The problem with withCredentials is that I do not understand how to propagate the provided password when running a shell command that prompts for a password after the function has been executed.

I have not been able to find clear information on what kind of permissions the agent user should have when executing pipeline steps. Should I always aim to develop pipelines that do not use commands requiring sudo permissions? Is this considered best practice?

Can anyone provide a link to the Jenkins documentation on how to handle sudo permissions in a Pipeline?

Best regards,
Alexander Bohn

2

Hello Jenkins Community,

can anyone provide an answer to the questions?

3

Hi Alexander,

Great question on sudo in Jenkins pipelines! Best practice is to avoid sudo for security and portability, running agents as non-privileged users with minimal permissions. If sudo is needed, configure /etc/sudoers for passwordless execution of specific commands

jenkins ALL=(ALL) NOPASSWD: /usr/bin/specific_command

Using withCredentials for sudo passwords is tricky, as it doesn’t handle interactive prompts well. You can try:

withCredentials([usernamePassword(credentialsId: 'sudo-creds', passwordVariable: 'PASS')]) {
    sh 'echo $PASS | sudo -S specific_command'
}

However, this is less secure; use sudoers instead. Ensure the agent user has workspace access and limit “Configure Agents” permissions to admins. Update Credentials/Pipeline plugins for secure handling in Jenkins 2.504.1 (Java 21-compatible).

Docs:

Best, David Mano

4

As sudo is a dangerous command it should be only be used when there is no other way.
If it is just a single command that needs to be executed you could consider creating a script for that command and explicitly put that script in the sudoers file and allow the user that runs the Jenkins agent to execute this script (and only this script) via sudo without even asking for a password.
If you need more flexibility you will need to pass the password for sudo on each execution.
Usually sudo is setup so that once you provided the password it will not ask again for the password for 1 or 2 minutes.
So the following should work

withCredentials([string(credentialsId: 'sudo', variable: 'SUDO_PW')]) {
  sh ''' 
    echo $SUDO_PW | sudo -v -S
    sudo mycommand ...
  '''
}

The exact parameters for sudo might depend on the OS
Beware what you execute with sudo, e.g. it should not be any parameter that a user can provide to run the job.

5

Hello David and Markus,

Thank you for the answers you provided.

Best regards,
Alexander Bohn

6

There are no hard requirements on this from Jenkins side. Jenkins on its own is perfectly capable of running without sudo priveleges – at least unless you add Docker to the equation.

If you can get away without needing sudo – that’s great, and striving to achieve such state is a noble goal. Both at $previousJob and $currentJob we had to grant sudo access to the agent user, since there was just too many legacy stuff that required it.
Generally speaking, I would say that it all depends upon where you draw the line of “if the malicious gets to this point, we are already screwed” – in both cases for us that was waaay before the Jenkins.

If you decide to go this way – do invest in VMs for your agents, configured-as-code in such way that you’d be able to recreate one from scratch in no time. So that if an accidental sudo rm -rf / would nuke a precious snowflake buildmachine, which is the only one capable of some arcane tasks, you’d halt only for a few hours instead of few days.

7

Hello Artalus,

Thank you for your answer and for joining the discussion.

Best regards,
Alexander Bohn