Kubernetes 如何在GitOps设置中保护环境repo？

在GitOps设置中，通常有两个存储库—代码repo和环境repo。我的理解是，分离repo有一些安全好处，因此开发人员只需要获得对代码repo的访问权，而environment repo的写访问权可以仅限于CI/CD工具。由于环境回购是GitOps中的真理之源，这被认为是更安全的，因为它最大限度地减少了人类在这一过程中的参与

我的问题是：

如果上述假设是正确的，那么应该授予哪些CI/CD工具访问环境repo的权限？它是仅仅是管道工具，如Tekton（CI）和Flux（CD），还是管道调用的其他工具也可以包含在这个“可信圈”中？在GitOps中保护环境回购的最佳实践是什么

围绕将集群的中间/动态状态同步回环境repo（例如，由HPA控制的部署中的副本数量、由服务网格提供商（例如，Istio）控制的网络路由）的思考过程是什么。？从我所看到的情况来看，大多数CD管道只是从环境repo到集群进行单向同步，而不是相反。但保留一些中间状态可能会有好处，例如，如果需要从环境repo重新创建其他集群

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

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

开发团队应该可以访问这两个回购协议。他们需要能够更改代码，并且需要能够更改不同环境的应用程序配置。构建工具（例如，来自Tekton管道的构建工具）可能只需要对配置repo具有写访问权限，但对两个repo都具有读访问权限

围绕将集群的中间/动态状态同步回环境repo（例如，由HPA控制的部署中的副本数量、由服务网格提供商（例如，Istio）控制的网络路由）的思考过程是什么。？从我所看到的情况来看，大多数CD管道只是从环境repo到集群进行单向同步，而不是相反

尽量避免将“当前状态”同步回Git回购，这只会很复杂。对您来说，只有在回购中保持“所需状态”才有价值，这有助于查看（例如）谁在何时更改了什么，也有助于灾难恢复或创建新的相同群集