譯者 | 朱鋼
審校 | 梁策 孫淑娟
DevOps在自動化、可追溯性方面的優勢已得到廣泛認可，此外它還能助力從前孤立的團隊和利益相關者展開協作。但是，隨著 DevOps 團隊越來越多地承擔將運營轉移到容器化的Kubernetes 環境的任務，久經考驗的 DevOps 實踐也可能棋差一著。如今，安全和風險問題正以不同的方式表現出來。
好消息是，在分布式環境的安全方面，GitOps 填補了 DevOps 中的許多空白。 由于GitOps 流程非常有利于 DevSecOps，此處定義為適用于整個應用程序生命周期的安全最佳實踐。
在本文中，我們將了解 GitOps 如何為 DevSecOps 提供基本框架，在整個 CI/CD 以及 Kubernetes 集群上應用程序管理部署后的階段進行安全檢查。
單一不變的事實來源
GitOps 可以定義為：
Kubernetes 和其他云原生技術的運營模型，它提供一組最佳實踐，統一容器化集群和應用程序的 Git 部署、管理和監控。
它是實現開發人員管理應用程序經驗的途徑;其中，端到端 CI/CD 管道和 Git 工作流應用于運營和開發。
正如此處聲明了所需的配置， Git 是單一的事實來源。 Kubernetes 內部運行了一個 GitOps 代理，它不斷將 Kubernetes 內部的實際狀態與存儲在 Git 中的所需狀態進行比較。 任何合并到 Git 中受監控分支的新更改都會自動應用于 Kubernetes。 相反，任何直接應用于 Kubernetes 的手動更改都會自動恢復到 Git 中聲明的所需狀態。配置漂移得到了消除。
由于其不可變的結構，Git 通常被描述為適用于 GitOps 的單一事實來源。除其他事項外，它還有助于維護一個邊界(與防火墻不同)，該邊界將 CI 和 CD 之間的問題分開。通過這種方式，作為CI的一部分，應用程序開發中涉及的步驟數量(拉取請求，測試，提交等) 在Git上保持獨立。
對于提出拉取請求的開發人員，拉取請求在審查和批準后會被合并，并在下一次協調時自動應用于集群(一般需要 15 分鐘)。
默認情況下，該過程是雙向的——這意味著當下一個協調循環運行時(通常每 15 分鐘一次)，直接對 Kubernetes 所做的更改會在 Git 上得到響應。但是，當 DevOps 團隊成員或非法行為入侵者直接對集群進行更改時，這種情況并不理想。這些直接到集群的更改沒有通過合并請求和批準，因此違反了 GitOps 原則，即當發生漂移時 Git 作為不可變的事實來源。
作為一種幫助減少漂移發生的解決方案，GitOps 監控工具可以在對集群作出更改而未先在 Git 中應用時發送警報。當這種情況發生時，由于審計跟蹤，通過運行時環境中處于部署狀態的控制器，Git 上的應用程序代碼可以替換對集群所做的錯誤更改。
相反，如果不變性沒有實現，就會發生漂移。這可能在網絡攻擊的情況下發生，或 DevOps 團隊成員無意更改了集群配置，使其與 Git 上的配置不同。出現這種情況時，使用適當的 GitOps 工具能夠將不一致標記出來，從而代表 GitOps 流程提供的典型 DevSecOps。
適當的工具可以自動執行持續監控的過程，以確保 Git 存儲庫中配置的所需狀態與 Kubernetes 集群中的實際狀態相匹配。 一旦它們在存儲庫的聲明狀態中正確提交，就會用于協調和完成部署。
審計控制
GitOps 提供的審計功能也是 DevSecOps 支持的關鍵。 通過保留在 Git 存儲庫中作為單一事實來源，所有應用程序、代碼和配置都進行了版本控制，并保留了完整的審計跟蹤，這是任何安全環境的主要要求。此審計跟蹤通常也可供開發人員和運營團隊成員使用，以便他們觀察集群中正在運行的內容(大多數用戶僅限于只讀訪問集群配置)。
開發人員不一定需要像運營和 DevSecOps 團隊成員那樣依賴審計跟蹤，但他們可以利用這種能力來了解發生了哪些變化以及對存儲庫進行更改的動機是什么。簡而言之，對于開發人員 (以及所有 DevOps 團隊成員)一切都只是一個 Git 日志的問題。
Git 上的審計跟蹤也可供開發人員在需要時輕松查找。這是因為系統的完整歷史記錄在 Git 記錄系統中，開發人員可以理解這一點。
借助審計跟蹤的可用性，開發人員還可以輕松回滾導致問題的應用程序的更改。 當集群遭到破壞或配置錯誤時，這尤其有用。 在這種情況下，審計跟蹤無需從頭開始重建集群，而是在存儲庫中包含所需的狀態， 然后部署具有審計跟蹤所需狀態的集群配置和應用程序，并自動重建過程。
很少有“萬能鑰匙”
開發人員通常依靠 Jenkins(一種自動化服務器)來構建、測試和支持用于 Kubernetes 環境生產管道的 CI/CD。如果沒有 GitOps，開發人員在直接部署代碼時可能會直接訪問 Kubernetes 集群。換句話說，無論他們屬于組織內部還是作為遠程工作的承包商，這對開發人員來說可謂有了一把直接訪問生產環境的“萬能鑰匙”，但這不是一個理想的安全方案。
在上述情況下，只要錯誤的用戶(或更糟糕的入侵者)使用 KubeConfig 或 Kubectl 命令訪問生產環境中的集群，這些集群就可以從筆記本電腦上訪問。如果攻擊者破壞了 CI 系統和憑據集，那么他們還可以訪問 CI 系統有權訪問的任何群集。
GitOps 有助于防止用戶(或攻擊者)在不留下任何痕跡的情況下更改群集配置，這一點對于運營和安全團隊尤其重要，此外還有助于減輕開發人員的心理負擔。例如，通過訪問控制，開發人員通常不應該直接訪問 Kubernetes 節點和/或 kubectl 命令行。因此，GitOps 可以協調開發人員在 Git 中定義的任何內容，但除非開發人員具有特殊的訪問控制權限，否則不允許手動訪問 Kubernetes 集群或生產環境。
GitOps 的 DevSecOps 功能是阻止 CD 攻擊媒介場景的一種方式，從而保護這把"萬能鑰匙"。當GitOps運算符(如開源 Flux，下面將對此進行詳細介紹)在 Kubernetes 內部運行時，可以訪問集群，訪問控制仍保留在 Kubernetes 安全框架中。用戶訪問權限是通過向不同團隊和團隊成員的命名空間分配權限來確定的。
美國國防部(DoD)提供了一個有效利用DevSecOps和GitOps 的例子。最近，美國空軍首席軟件官尼古拉斯·查蘭(Nicolas Chaillan)講述了DevSecOps和GitOps如何與Flux一起在支持整個美國空軍保安部隊的軟件開發中發揮了關鍵作用。
查蘭表示，“安全和保障是不可讓步的問題，但我們也希望開發人員能通過自助服務提高生產力并加快速度。”
美國國防部表示，GitOps是“在整個國防部成功構建和推出‘平臺一號’(Platform One)的關鍵”。平臺一號是“一個經過批準，完全與云原生計算基金會(CNCF)的Kubernetes發行版兼容，同時還有基礎設施即代碼的劇本以及強化容器的集合"，具有內置的安全管道。
制衡
DevSecOps 流程與 GitOps 集成，提供制衡。因為所有拉取請求都經過評審，所以通過這種方式，它提供的訪問控制可以防止開發人員或入侵者訪問源代碼存儲庫，從而在CI過程中引入后門，零日漏洞或其他類型的漏洞。
由于 DevSecOps 支持 CI 進程，因此在 Git 上提交代碼并部署在群集中之前就已進行檢查和平衡。開發人員通常會將更改作為拉取請求提交，該請求會經過評審。一旦經過審查和批準，代碼就會合并到 Git 上，然后相應地更改所需狀態的 YAML 文件。
所需的狀態將自動應用于 Kubernetes 集群。如上所述，具有 DevSecOps 功能的適當 GitOps 工具會持續監控目標系統內的實際狀態，以確保它響應 Git 上聲明的內容。如果有任何差異，則會發出警報，因此可以采取糾正措施。
DevSecOps 自成一派
許多GitOps工具都支持DevSecOps。例如，開源 Flux 有助于維護 Git 存儲庫，使其成為單一不可變的事實來源。Flux 的功能還擴展到訪問控制，以便在 CI/CD 期間對提交和部署的代碼進行檢查和平衡。
對于更有個性的 Flux 體驗，開源 Weave GitOps Core 讓幫助跨多個集群自動化 CI/CD的起始步驟更簡化。此外，使用Weave GitOps Core設置GitOps和DevSecOps的過程涉及控制臺上的一些簡單命令。
Weave GitOps Enterprise 已成為第一個 GitOps 平臺，該平臺可在任何規模的混合云、多云和邊緣架構中為 Kubernetes 自動執行持續應用程序交付和自動化運營控制。
所有這三個工具都有助于自動執行監控，以確保群集配置始終與 Git 上的內容匹配，從而幫助防止漂移。完整且可訪問的審計跟蹤允許根據需要回滾應用程序和群集配置，而無需從頭開始重建群集。
總而言之，GitOps代表了分布式Kubernetes環境的DevOps的演變，而在整個應用程序生命周期中，DevSecOps已成為維護GitOps的CI / CD安全性的重要方式。
譯者介紹
朱鋼，51CTO社區編輯，2021年IT影響力專家博主，阿里云專家博主，2019年CSDN博客之星20強，2020年騰訊云+社區優秀作者，11年一線開發經驗，曾參與獵頭服務網站架構設計，企業智能客服以及大型電子政務系統開發，主導某大型央企內部防泄密和電子文檔安全監控系統的建設，目前在北京圖伽健康從事醫療軟件研發工作。
原文標題：??Why GitOps is crucial for DevSecOps??，作者：Steve Waterworth
