![使用 su 结合服务账户进行管理](https://linux22.com/image/749690/%E4%BD%BF%E7%94%A8%20su%20%E7%BB%93%E5%90%88%E6%9C%8D%E5%8A%A1%E8%B4%A6%E6%88%B7%E8%BF%9B%E8%A1%8C%E7%AE%A1%E7%90%86.png)
我们正在经历配置 sudoers 以获得最低权限的艰难过程。我们在会议上讨论了需要做什么,我们的经理建议,不要使用我们自己的 sudo 帐户,而是使用su <serviceaccount>
被管理的服务。这对我来说似乎有点奇怪,而且可能更难管理。我只使用 Linux 几年,而我的经理使用 Unix 已有 15 年以上,所以我不会在没有进行一些研究的情况下反驳。
我没有找到任何关于这种工作方式的文献,但是我的经理确实提到了一些有关重新启动服务和登录用户拥有该进程的问题。我想知道这是否是服务管理实用程序出现之前的遗留问题。我们使用的一切都将由 systemd 管理,所以我认为这不会成为问题。我还希望如果存在必须以服务帐户身份运行命令的情况,这将通过 来完成Runas_Alias
。
在 2020 年的当前环境下,将 su 与服务帐户一起使用而不是使用 sudoers 授予我们自己的帐户访问权限是否有效?
*** 补充说明
抱歉,如果我说得不清楚。服务将使用 systemd 等服务管理器运行。这将具有单元文件中指定的服务帐户。运行sudo systemctl start
将在单元文件中指定的帐户下启动进程。
我认为通过 ssh 以最小权限管理系统的最佳方式是使用以下命令以 root 身份运行所需命令:我的sudoers 中的用户帐户。文件编辑将使用 sudoedit 进行处理。
我的经理似乎建议,我们不应该使用我的用户在 sudoers 文件中添加命令,而应该将所有必要的访问权限授予服务帐户,并且我们应该使用su
以服务帐户身份运行来执行这些任务。
我觉得这没有意义。这似乎会更难管理,授予服务帐户比其需要的更多的访问权限,并且更难审核。
答案1
他的建议有很多原因,当您使用自己的帐户运行服务时会遇到的问题之一是:
1- 由服务帐户运行的服务会加载该帐户的环境变量,并且知道大多数服务都需要这些环境变量,因此无法使用您的用户帐户访问它们。
2- 当您使用您的帐户启动服务时,此服务创建的新文件将归您的用户所有。现在想象一下服务停止了,您的团队成员中的某个人试图重新启动它,一旦运行该服务,它将尝试访问最近创建的文件,但这些文件不可能归您的用户帐户所有。
3-另一种情况,您使用自己的帐户启动该服务,而您的团队成员之一由于某种原因尝试停止/暂停它,但由于缺乏权限,这也是不可能的。