使用Jenkins的sudo不好吗？

我使用“ 通过SSH发布”插件将我的应用程序部署Jenkins到不同的环境。一些部署作业会进行环境准备，诸如停止并重新启动应用程序服务器系统服务之类的事情。其中一些命令要求sudo。

我只是好奇在远程发布和执行Jenkins作业中要求sudo是否会是一种不良的安全做法。我们是否应该更改目标主机上的安全策略以允许执行所需功能而无需sudo？

不，当您需要更高级别的特权时，对sudo 来说实际​​上是一种很好的安全实践。这就是大多数发行版禁止默认登录并实际上迫使您sudo su输入而不是仅仅键入su-的原因，它们是为了鼓励您使用sudo来提高安全性。原因如下：

• 审核。进行sudo时，系统会记录谁进行了 sudo以及他们运行的命令。当您需要回头找出发生了什么事情-指责，进行恶意活动或仅用于故障排除时，这在法医上增加了很多（在昨晚7PM发生在该服务器变为AWOL之前，到底发生了什么？）

• 须藤规则。仅仅因为用户需要使用已升级的特权来运行某些内容，并不意味着他们需要使用已升级的特权来运行所有操作。使用su或将用户添加到wheel允许用户执行所有操作。但是，使用sudo可以使用允许使用通配符的命令别名来指定用户可以做什么和不能做什么，从而允许灵活的规则允许用户使用某些命令而不使用其他命令。

• 硬化。可以禁用root。同样，出于所有意图和目的，它并不存在，仅在单用户模式下有用/可用-需要重启服务器（允许这样做的唯一原因是密码恢复）。sudo su不再有效。这是通过将root用户的shell设置为/ bin / nologin来完成的。这是防止许多根升级漏洞的好方法。当然，这是假定您正确使用了上面的项目符号（并且您仍然可以向特定的管理员用户授予所有权限，尽管这会破坏您的安全性）。

当然，这些只是安全模型的一部分。例如，除非您没有具有完全管理权限的用户（有时甚至是那时），否则您的用户可能（可能）删除日志和历史记录-除非您使用日志服务器和syslog出厂时将日志发送出去。那就没有办法把那只猫放回书包里了。当然，如果您使用中央身份验证目录结构，则它会重新发挥作用：如果我破坏了一个帐户，则该帐户将在组织中的所有服务器（包括您的日志服务器）上也受到破坏。

简而言之，安全性很复杂，但是sudo是设计安全环境的一个很好的工具，更多的人应该充分利用它。

无论允许远程sudo访问还是远程访问SUID root具有相似攻击面的内容。我会保持联系sudo，因为它使您可以轻松地限制命令，并且具有日志记录，这对于以后需要审核的内容至关重要。 sudo在生产上也有悠久的历史。进行其他操作将减少历史记录，并增加不愉快惊喜的变化。

但是，您还可以采取其他措施使此操作更加安全：

• 勒紧，加强 ssh
• 仅允许一些特定用户使用重新启动命令，包括jenkins
• 仅允许从所有内部IP或jenkins和跳转框IP的特定用户登录
• 将日志存储在远程邮箱上，以免它们被垃圾掩盖