Whether you allow remote sudo or remote access to something that does SUID root you have a pretty similar attack surface. I would keep sudo in the chain because it lets you limit the commands easily and has logging that will be vital if you need to audit things later.

There are other things you can do to make this more secure though:

• tighten up ssh
• only allow the restart commands for a few specific users including one for jenkins
• only allow logins for those specific users from all internal IP's or just jenkins and jump box IP's
• store logs on remote boxes so they can't be mucked with

Whether you allow remote sudo or remote access to something that does SUID root you have a pretty similar attack surface. I would keep sudo in the chain because it lets you limit the commands easily and has logging that will be vital if you need to audit things later. sudo also has a much longer history in production. Doing something else will have less history and higher changes of unpleasant surprises.

There are other things you can do to make this more secure though:

• tighten up ssh
• only allow the restart commands for a few specific users including one for jenkins
• only allow logins for those specific users from all internal IP's or just jenkins and jump box IP's
• store logs on remote boxes so they can't be mucked with