That line won’t work because you haven’t given
visudo a command for
gitlab-runner to run.
It is forbidden (or should be!) in your operating system for one user to “pretend” to be another, without root privileges. Otherwise, a user could log on and change all the files and so on that belong to another user. This isn’t something specific to
You may well be tempted to do this:
gitlab-runner ALL=(ALL) NOPASSWD:ALL su another-user
I would advise against it, because you are giving
gitlab-runner permission to run /any/ command as
another-user, and if somehow someone breached your security, and ran their own scripts on your machine, they would have a lot of scope to do damage.
Probably, you have a situation where you want to deploy a web app to a web server, your web server will (by design) have limited privileges, and it’s important not to change that, as any web server is a potential vector of attack.
What I would suggest, as good practice (I won’t say best practice, someone may well have better ideas) is:
- You run the smallest possible set of commands with special privileges
- Anything you run in
gitlab-runner that needs
visudo should be checked into version control. So, either you have commands in
.gitlab-ci.yml calls a script that’s in your repo. That means that if you see a pipeline somewhere has messed something up, you can look at the timestamp and see what code was run, even if it’s been deleted from the server.
- Wherever possible, it makes sense to do as much of your deployment as possible as
gitlab-runner with normal permissions, and then only use commands in
visudo right at the end of the deployment. That way, if anything goes wrong in the middle, any problems will have caused you the least possible amount of damage, and you won’t need to roll back a live deployment.
I do realise this makes setting up a good deployment pipeline a bit trickier, and it’s a bit more work. Hopefully, in the long term more caution now will mean fewer bug fixes and maintenance jobs.