GitOps——安全视角（第一部分）

Kubernetes——GitOps 的得力助手

GitOps 适合你吗？

GitOps与安全

结论

GitOps是一种以 Git 为核心的云原生应用构建和运维范式，它将 Git 作为单一数据源，使开发人员能够执行以往由 IT 运维人员负责的工作。本文是关于 GitOps 和 Kubernetes 安全性的系列博客文章之一。

Kubernetes——GitOps 的得力助手

Kubernetes作为新型应用服务器，在构建云原生应用时采用了“声明式”方法，这意味着应用配置由一组事实而非一组指令来保证。通过将应用声明版本化到 Git 中，我们拥有了单一数据源，应用可以轻松地部署到 Kubernetes 并进行回滚，并且在发生灾难时，集群的基础设施也可以被快速恢复。

以 Git 为交付管道的核心，开发人员可以发出拉取请求，从而加速和简化应用程序部署和运维任务到 Kubernetes。

GitOps 适合你吗？

GitOps + Kubernetes 为应用交付生命周期带来的全新方法无疑与众不同，它不仅提高了工程效率，还简化了 CI/CD 流水线的构建。GitOps 的“拉取”模式是否比“推送”模式更合适，实际上取决于组织的工程和运维文化，甚至可以说是一个关乎工程是否负责安全以及安全团队需要对这个应用服务器黑盒具备何种可见性的基本问题。

GitOps与安全

1. GitOps 变更仅通过集群 Git 仓库用户同步到集群。仓库的安全级别与 Git 用户帐户相同。如果拥有推送至集群 Git 仓库权限的用户帐户被盗用，则可能导致数据泄露、服务中断或介于两者之间的任何后果。因此，GitOps 基础设施必须实施额外的安全防护措施，例如白名单机制，以确保集群层面的安全。

2. 像Flux、ArgoCD等GitOps 工具实际上拥有集群的全局权限，并且持久存在于集群中。Kubernetes Dashboard 被认为对集群构成高风险，因此通常会从集群中移除。而像Spinnaker、Jenkins
   等 基于“推送”的持续交付 (CD) 流水线则位于集群外部，按需调用，并将自动化驱动的变更引入集群。

   

   示例：Flux RBAC 权限- 集群上帝 * * * * *

3. 像 Flux、ArgoCD 等 GitOps 工具需要集群外部访问权限，以域名（github.com、bitbucket.org、gitlab.com 等）表示，这意味着Kubernetes 原生策略不适合用于隔离集群内这些高权限组件。

4. 在 GitOps 时代，应用程序密钥需要 Kubernetes 外部密钥提供程序，例如HashiCorp Vault、AWS KMS和Azure Vault等。或者，团队也可以选择使用Git Secrets，即将密钥以加密形式提交到 Git，并在应用程序使用前解密。

结论

Kubernetes 生态系统中的持续集成/持续开发 (CI/CD)提供了多种工具可供选择，组织应根据自身特定的用例和文化选择最合适的工具。将所有组件整合在一起并非易事。集成安全性并让不同的利益相关者使用安全洞察同样是一项极具挑战性的任务。GitOps 在某些方面简化了这一过程，但在其他方面却使其更加复杂。

敬请期待第二部分。

参加我们即将于 4 月 22 日举行的网络研讨会：GitOps 最佳实践：持续部署和渐进式安全。