【问题标题】：How to secure the environment repo in a GitOps setup?如何在 GitOps 设置中保护环境存储库？
【发布时间】：2021-05-05 01:12:17
【问题描述】：
在 GitOps 设置中，通常有两个存储库 - 代码存储库和环境存储库。我的理解是分离存储库有一些安全优势，因此开发人员只需要获得对代码存储库的访问权限，并且环境存储库的写入访问权限可以仅限于 CI/CD 工具。由于环境 repo 是 GitOps 中的真实来源，因此据称这更安全，因为它最大限度地减少了人类对流程的参与。
我的问题是：
-
如果上述假设是正确的，应该授予哪些 CI/CD 工具访问环境 repo 的权限？仅仅是Tekton（CI）和Flux（CD）这样的流水线工具，还是流水线调用的其他工具也可以包含在这个“信任圈”中？在 GitOps 中保护环境存储库的最佳实践是什么？
-
关于将集群的中间/动态状态同步回环境存储库的思考过程是什么，例如，由 HPA 控制的部署中的副本数量，由服务网格提供商（例如，Istio）控制的网络路由）， ETC。？据我所见，大多数 CD 管道只是从环境 repo 到集群进行单向同步，而不是相反。但是保留一些中间状态可能会有好处，例如，如果需要从环境 repo 重新创建其他集群。
【问题讨论】：
标签：
kubernetes
continuous-integration
continuous-deployment
continuous-delivery
gitops
【解决方案1】：
通常有两个存储库 - 代码存储库和环境存储库。我的理解是，分离 repos 有一些安全优势，因此开发人员只需要被授予对 code repo 的访问权限，并且环境 repo 的写访问权限可以仅限于 CI/CD 工具。
在实践任何形式的持续交付时，最好有一个单独的代码仓库和配置仓库。这在“经典”Continuous Delivery 书中有所描述。原因是两个 repos 在不同的周期中变化，例如首先更改代码，在管道验证更改后，可以更新配置 repo，例如图片摘要。
开发人员团队应该可以访问这两个存储库。他们需要能够更改代码，并且需要能够针对不同的环境更改应用程序配置。构建工具，例如来自 Tekton 管道可能只需要对 config repo 的写入权限，但对两个 repos 的读取权限。
关于将集群的中间/动态状态同步回环境存储库的思考过程是什么，例如，由 HPA 控制的部署中的副本数量，由服务网格提供商（例如，Istio）控制的网络路由）， ETC。？据我所知，大多数 CD 管道只是从环境 repo 到集群进行单向同步，而不是相反。
尽量避免将“当前状态”同步回 Git 存储库，这只会很复杂。对你来说，只有在回购中保持“期望的状态”才是有价值的——看看例如谁更改了什么时间 - 还用于灾难恢复或创建一个新的相同集群。