GitOps 新一代大型自动化工具（3）

Gitops安全篇​

​        GitOps是一种范式，​它将 Git 置于构建和操作云原生应用程序的核心，将 Git 用作单一事实来源，并使开发人员能够执行过去属于 IT 操作的任务。

Kubernetes - GitOps 

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

使用 Git 作为交付管道的中心，开发人员可以发出拉取请求，以加速和简化 Kubernetes 的应用程序部署和操作任务。

GitOps 适合你？

GitOps + Kubernetes 为应用程序交付生命周期带来的新方法无疑是不同的，它提高了工程速度，并简化了 CI+CD 管道本身的构建。GitOps“拉”方法是否比“推”方法更适合的问题实际上是一个组织的工程和运营文化问题，以及工程是否对安全负责以及对安全的可见性几乎是一个神学问题这个应用服务器黑盒，安全团队需要。

GitOps 与安全

1. GitOps 更改仅通过集群 git 存储库用户同步到集群中。存储库在 git 用户帐户的同一级别受到保护。有权推入集群 git 存储库的受损用户帐户可能会引入更改，从而导致数据泄露、服务中断或介于两者之间的任何情况。GitOps 基础设施必须以白名单的形式实施额外的护栏，以便拥有集群侧护栏。

2. ​Flux、ArgoCD等​ GitOps 工具实际上以集群上帝权限运行 - 并且在集群中持久存在。被认为是高风险集群的 Kubernetes Dashboard 经常被从集群中移除。
   基于“推送”的 CD 管道，​例如Spinnaker、Jenkins等在集群外部，​按需调用，并将自动化驱动的更改引入集群。

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 在某些方面简化了这一点，但在其他方面复杂化了。