如何在GitOps设置中保护环境回购？

Question

在GitOps设置中，通常有两个存储库--代码回购和环境回购。我的理解是，分离repos有一些安全好处，因此开发人员只需要获得对代码回购的访问权限，而环境回购的写访问权限只能限于CI/CD工具。由于环境回购在GitOps中是真理的来源，这被认为是更安全的，因为它将人类参与这一过程的程度降到最低。

我的问题是：

1. 如果上面的假设是正确的，那么应该允许哪些CI/CD工具访问环境回购？是只有管道工具，如Tekton (CI)和Flux (CD)，还是管道调用的其他工具也包括在这个“可信循环”中？在GitOps中保护环境回购的最佳实践是什么？
2. 围绕将集群的中间/动态状态同步回环境回购的思想过程是什么，例如，由HPA控制的部署中的副本数量，由服务网格提供者(例如Istio)控制的网络路由，等等？据我所见，大多数CD管道只进行从环境回购到集群的单向同步，而不是相反。但是，保持一些中间状态可能会有好处，例如，如果需要从环境回购中重新创建其他集群。

Answer 1

通常有两个存储库--代码回购和环境回购。我的理解是，分离repos有一些安全好处，因此开发人员只需要获得对代码回购的访问权限，而环境回购的写访问权限只能限于CI/CD工具。

在实践任何形式的连续交付时，使用单独的代码回购和配置回购是一个很好的实践。这在“经典”连续交付书中有描述。原因是这两个回复在一个不同的周期中发生变化，例如，首先代码被更改，并且在管道验证了更改后，可以使用例如图像摘要( Image )来更新配置回购。

开发团队应该能够访问这两个repos。他们需要能够改变代码，他们需要能够改变不同环境的应用程序配置。构建工具，例如来自Tekton管道的工具，可能只需要对配置回购进行写访问，但是需要读取对这两个repos的访问权限。

围绕将集群的中间/动态状态同步回环境回购的思想过程是什么，例如，由HPA控制的部署中的副本数量，由服务网格提供者(例如Istio)控制的网络路由，等等？据我所见，大多数CD管道只进行从环境回购到集群的单向同步，而不是相反。

尽量避免将“当前状态”同步回Git回购，这只会很复杂。对您来说，将“期望状态”保持在回购中是有价值的--例如，查看谁更改了什么时候--但是对于灾难恢复或创建一个新的相同的集群也是有用的。