我正在寻找一种自动化方法：我有许多 Linux 服务器，我希望能够在它们上运行一些脚本，而无需通过 ssh 登录服务器并手动运行任务，
我想要一个统一的指挥中心，可以在服务器上运行特定的预定义任务。
我知道有ansible等几个工具可以满足这个需求，
但我还有另一个要求：我想限制命令中心能够运行预定义的任务并且绝对地而已。因此，如果命令中心完全受到攻击，攻击者只能执行预定义的任务，任何为命令中心提供 ssh 访问权限的解决方案都与此要求相矛盾。
我搜索并尝试了一些工具，但没有一个适合我的需求。
答案1
正如您所发现的，其他人构建的解决方案并不能解决您的网络中存在的问题，这些网络是根据您的雇主/组织施加的要求/限制为您的用例提供服务的。
也就是说，您不能只是从互联网上复制解决方案，将其粘贴到您的架构中，然后让它完美地为您工作。您必须对其进行自定义以满足您的要求/需求。
我们都会经历学习这个的过程。你也在学习它。欢迎来到俱乐部。
就您而言，有多个配置管理套件可以处理解决方案中在服务器上执行更改/操作的部分。 Ansible、Chef、Puppet、Saltstack 等可以完成此部分，通常通过 root 访问（直接或通过 sudo）。但是，虽然它们每个都可以对允许哪些用户调用它们进行一些规定，但它们无法完全满足您的要求。
但是该层调节（控制）可以由另一个软件套件处理，与您的配置管理系统一起工作。例如，您可以使用 Jenkins 等 CI/CD 平台来调用 Ansible playbook。想象一下这样一种架构，其中 Ansible 使用特权访问来完成您需要的自动化任务，但只有 Jenkins 工作计算机才有权调用 Ansible playbook。 Jenkins 配置控制允许哪些用户运行 playbook。您可以获得可以完成工作的自动化任务，并控制谁可以运行哪些任务。这组合Ansible 和 Jenkins 的结合可以满足您所有的安全和业务需求。
由于这更像是一组基础设施/操作任务，因此您可以从软件开发人员用来部署自定义应用程序的实例中创建一个单独的 Jenkins 实例。
必须是 Ansible 和 Jenkins 吗？不。我建议它们是因为它们被广泛使用，并且您可能可以想象将它们一起使用。如果您更熟悉其他 CI/CD 套件或其他配置管理套件，则可以使用它们。我想提供的想法是将两个（或更多）软件套件作为构建块组合起来，以创建满足您所有需求的完整解决方案。