对于通过GitLab Piplines的零部署-什么类型的unix用户？

Question

我想为我的网页服务器实现一个零部署策略。

我的第一次尝试是为此创建一个特定的用户(部署人员)：

# Create user deployer
sudo adduser deployer
# Give the read-write-execute permissions to deployer user for directory /var/www
sudo setfacl -R -m u:deployer:rwx /var/www

使用GitLab和一些教程(如这或这 )，我尝试将部署过程自动化。

但是，我被困住了，因为我的用户deployer需要sudo权限来触发一些特定的命令。

现在，我想知道这会不会是个问题？因为我将私有ssh密钥给用户部署人员，所以gitlab可以连接到服务器。

因为理论上gitlab可以被黑，所以我的服务器也可以被黑。

你认为如何？或者风险太小了，所以我不需要担心。

Answer 1

基础

是的，如果您在Gitlab中存储服务器的访问凭据，而Gitlab被攻击，那么您的服务器可能会被黑客攻击。如果部署应用程序的用户需要根访问，那么您别无选择，只能将根访问授予gitlab (或者调整您的应用程序，这样就不需要根访问了)。

用户访问级别

您似乎特别关注给予Gitlab根访问服务器的权限。当然，如果可能的话，应该避免这种情况，但这并不一定是最大的担忧。毕竟，如果您的服务器所做的唯一事情就是承载您的应用程序，那么作为部署者用户入侵的人已经可以访问所有感兴趣的东西。在那个时候，让用户根也不会使它变得更加危险。

下一步

在一个理想的世界里，它不会是一个“服务器”的问题。例如，如果您在某个专用服务器上运行，那么根就会受到损害，这肯定是一件痛苦的事情。但是，如果您更进一步，并且从(例如) Docker映像中提供了一个VPS或Kubernetes集群，那么让任何一个“服务器”被破坏就不那么麻烦了。您只需解决导致妥协的根本问题，并在全新的“服务器”上重新部署。显然，漏洞总是很糟糕的，我并不想说相反的话，但我的观点是，在运行良好的基础设施中，对“服务器”的关注可能要少得多，这是一件好事。

你应该把访问密钥放进Gitlab吗？

是否你的Gitlab帐户被泄露的风险是你应该担心的问题，只有你才能回答。下面是您需要问自己的一个问题：“自动化部署的好处值得我的服务器受到威胁吗？”

这实际上是一个简单的风险评估。当然，要回答，你需要知道妥协的可能性，这是很难回答的。但要明确的是，Gitlab本身被黑客攻击的可能性比您的安全错误更小，即：

1. 确保您在Gitlab上使用了一个强的唯一密码。
2. 启用安全的2FA帐户
3. 确保您遵循有关为CI/CD脚本存储机密的最佳实践。

另外，请记住，这只是服务器可能被破坏的许多可能的方法之一。确保您的CI/CD管道具有良好的安全性只是一个优先事项，如果同时在您的服务器上运行了一个打开的FTP服务器，或者您的应用程序没有遵循应用程序安全性的基本知识，那么您有更多的事情要做。

但是，最后，只有您可以决定这个额外的自动化步骤是否值得为您增加风险。