在 GitOps 设置中，通常有两个存储库 - 代码存储库和环境存储库。我的理解是，分离 repos 有一些安全优势，因此开发人员只需要获得对代码 repo 的访问权限，并且环境 repo 的写访问权限可以仅限于 CI/CD 工具。由于环境 repo 是 GitOps 中的真实来源，因此据称这更安全，因为它最大限度地减少了人对过程的参与。
我的问题是：
如果上述假设是正确的，应该授予哪些 CI/CD 工具访问环境 repo 的权限？是只是Tekton（CI）、Flux（CD）等流水线工具，还是流水线调用的其他工具也可以包含在这个“信任圈”中？在 GitOps 中保护环境存储库的最佳实践是什么？
将集群的中间/动态状态同步回环境存储库的思考过程是什么，例如，由 HPA 控制的部署中的副本数量、由服务网格提供商（例如，Istio）控制的网络路由等.? 据我所见，大多数 CD 管道只进行从环境 repo 到集群的单向同步，而不是相反。但是保留一些中间状态可能会有好处，例如，如果需要从环境 repo 重新创建其他集群。
通常有两个存储库 - 代码存储库和环境存储库。我的理解是，分离 repos 有一些安全优势，因此开发人员只需要获得对代码 repo 的访问权限，并且环境 repo 的写访问权限可以仅限于 CI/CD 工具。
在练习任何形式的持续交付时，拥有单独的代码仓库和配置仓库是一个很好的做法。这在“经典”持续交付书中有所描述。原因是两个存储库在不同的周期中更改，例如首先更改代码，然后在管道验证更改后，可以对配置存储库进行更新，例如 Image Digest。
开发人员团队应该可以访问这两个存储库。他们需要能够更改代码，并且需要能够针对不同的环境更改应用程序配置。构建工具（例如来自 Tekton 管道）可能只需要对 config repo 的写访问权，但对两个 repo 的读访问权。
将集群的中间/动态状态同步回环境存储库的思考过程是什么，例如，由 HPA 控制的部署中的副本数量、由服务网格提供商（例如，Istio）控制的网络路由等.? 据我所见，大多数 CD 管道只进行从环境 repo 到集群的单向同步，而不是相反。
尽量避免将“当前状态”同步回 Git 存储库，这只会很复杂。对您而言，只有在存储库中保持“所需状态”才是有价值的——例如查看谁更改了什么时间很有用——而且对于灾难恢复或创建一个新的相同集群也是有用的。