问题描述
在使用Jenkins的Publish Over SSH插件将应用程序部署到不同的环境时，有一些部署作业需要执行一些需要sudo权限的命令，他想知道在远程发布和执行Jenkins作业中使用sudo是否会导致安全问题。是否应该更改目标主机上的安全策略，以允许在不使用sudo的情况下执行所需的功能？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
解决方案1
在远程使用sudo或允许访问具有SUID root权限的其他内容时，攻击面相似。我建议保留sudo，因为它可以轻松限制命令，并且具有日志记录功能，如果需要审计事务，这将非常重要。sudo在生产中的历史更长。使用其他方法可能会有更少的历史记录，并且可能会有令人不愉快的意外。
但是，您可以采取其他措施来增强安全性：
– 加强ssh安全性
– 仅允许特定用户（包括jenkins用户）执行重启命令
– 仅允许这些特定用户从所有内部IP或仅允许jenkins和跳板IP登录
– 将日志存储在远程主机上，以防止被篡改
解决方案2
使用sudo在需要更高权限时是非常好的安全实践。这也是大多数发行版禁止默认登录并强制你使用
sudo su而不是直接使用su的原因-他们希望鼓励你使用sudo的安全性好处。以下是一些原因：
– 审计：当你使用sudo时，系统会记录谁使用sudo以及他们运行的命令。这在需要追溯发生了什么时非常有用，比如追查问题、捕捉恶意活动或进行故障排除。
– Sudo规则：只因为用户需要以提升的权限运行某些命令，并不意味着他们需要以提升的权限运行所有命令。使用su或将用户添加到wheel组允许用户执行所有操作。但是，使用sudo可以使用命令别名来指定用户可以执行和不能执行的命令，这样可以灵活地控制权限。
– 强化安全性：可以禁用root用户。也就是说，从实质上讲，root用户不存在，只有在单用户模式下才能使用它-需要重新启动服务器（唯一允许的原因是为了密码恢复）。sudo su不再起作用。这是通过将root的shell设置为/bin/nologin来实现的，这是一种防止许多root提升漏洞的好方法。当然，这假设您正确使用了上面的方法（您仍然可以授予特定的管理员用户所有权限，但这将破坏您的安全立场）。
当然，这些只是安全模型的一部分。例如，除非您没有具有完全管理权限的用户（有时即使有），否则您的用户可能能够删除日志和历史记录-除非您使用日志服务器和syslog将日志发送到远程服务器。然后就没有办法恢复了。当然，如果您使用集中身份验证目录结构，那么这又回到了原点：如果我入侵一个帐户，那么该组织中的所有服务器都会受到影响-包括可能是您的日志服务器。
简而言之，安全性是复杂的，但sudo是设计安全环境的一个很好的工具，更多的人应该充分利用它。
最佳解决方案是使用sudo，因为它提供了更好的安全性和灵活性。您可以根据需要配置sudo规则，并使用sudo的日志记录功能进行审计。