譯者 | 朱鋼

審校 | 梁策 孫淑娟

DevOps在自動(dòng)化、可追溯性方面的優(yōu)勢(shì)已得到廣泛認(rèn)可，此外它還能助力從前孤立的團(tuán)隊(duì)和利益相關(guān)者展開協(xié)作。但是，隨著 DevOps 團(tuán)隊(duì)越來越多地承擔(dān)將運(yùn)營轉(zhuǎn)移到容器化的Kubernetes 環(huán)境的任務(wù)，久經(jīng)考驗(yàn)的 DevOps 實(shí)踐也可能棋差一著。如今，安全和風(fēng)險(xiǎn)問題正以不同的方式表現(xiàn)出來。

好消息是，在分布式環(huán)境的安全方面，GitOps 填補(bǔ)了 DevOps 中的許多空白。 由于GitOps 流程非常有利于 DevSecOps，此處定義為適用于整個(gè)應(yīng)用程序生命周期的安全最佳實(shí)踐。

在本文中，我們將了解 GitOps 如何為 DevSecOps 提供基本框架，在整個(gè) CI/CD 以及 Kubernetes 集群上應(yīng)用程序管理部署后的階段進(jìn)行安全檢查。

單一不變的事實(shí)來源

GitOps 可以定義為：

Kubernetes 和其他云原生技術(shù)的運(yùn)營模型，它提供一組最佳實(shí)踐，統(tǒng)一容器化集群和應(yīng)用程序的 Git 部署、管理和監(jiān)控。

它是實(shí)現(xiàn)開發(fā)人員管理應(yīng)用程序經(jīng)驗(yàn)的途徑;其中，端到端 CI/CD 管道和 Git 工作流應(yīng)用于運(yùn)營和開發(fā)。

正如此處聲明了所需的配置， Git 是單一的事實(shí)來源。 Kubernetes 內(nèi)部運(yùn)行了一個(gè) GitOps 代理，它不斷將 Kubernetes 內(nèi)部的實(shí)際狀態(tài)與存儲(chǔ)在 Git 中的所需狀態(tài)進(jìn)行比較。 任何合并到 Git 中受監(jiān)控分支的新更改都會(huì)自動(dòng)應(yīng)用于 Kubernetes。 相反，任何直接應(yīng)用于 Kubernetes 的手動(dòng)更改都會(huì)自動(dòng)恢復(fù)到 Git 中聲明的所需狀態(tài)。配置漂移得到了消除。

由于其不可變的結(jié)構(gòu)，Git 通常被描述為適用于 GitOps 的單一事實(shí)來源。除其他事項(xiàng)外，它還有助于維護(hù)一個(gè)邊界(與防火墻不同)，該邊界將 CI 和 CD 之間的問題分開。通過這種方式，作為CI的一部分，應(yīng)用程序開發(fā)中涉及的步驟數(shù)量(拉取請(qǐng)求，測(cè)試，提交等) 在Git上保持獨(dú)立。

對(duì)于提出拉取請(qǐng)求的開發(fā)人員，拉取請(qǐng)求在審查和批準(zhǔn)后會(huì)被合并，并在下一次協(xié)調(diào)時(shí)自動(dòng)應(yīng)用于集群(一般需要 15 分鐘)。

默認(rèn)情況下，該過程是雙向的——這意味著當(dāng)下一個(gè)協(xié)調(diào)循環(huán)運(yùn)行時(shí)(通常每 15 分鐘一次)，直接對(duì) Kubernetes 所做的更改會(huì)在 Git 上得到響應(yīng)。但是，當(dāng) DevOps 團(tuán)隊(duì)成員或非法行為入侵者直接對(duì)集群進(jìn)行更改時(shí)，這種情況并不理想。這些直接到集群的更改沒有通過合并請(qǐng)求和批準(zhǔn)，因此違反了 GitOps 原則，即當(dāng)發(fā)生漂移時(shí) Git 作為不可變的事實(shí)來源。

作為一種幫助減少漂移發(fā)生的解決方案，GitOps 監(jiān)控工具可以在對(duì)集群作出更改而未先在 Git 中應(yīng)用時(shí)發(fā)送警報(bào)。當(dāng)這種情況發(fā)生時(shí)，由于審計(jì)跟蹤，通過運(yùn)行時(shí)環(huán)境中處于部署狀態(tài)的控制器，Git 上的應(yīng)用程序代碼可以替換對(duì)集群所做的錯(cuò)誤更改。

相反，如果不變性沒有實(shí)現(xiàn)，就會(huì)發(fā)生漂移。這可能在網(wǎng)絡(luò)攻擊的情況下發(fā)生，或 DevOps 團(tuán)隊(duì)成員無意更改了集群配置，使其與 Git 上的配置不同。出現(xiàn)這種情況時(shí)，使用適當(dāng)?shù)?GitOps 工具能夠?qū)⒉灰恢聵?biāo)記出來，從而代表 GitOps 流程提供的典型 DevSecOps。

適當(dāng)?shù)墓ぞ呖梢宰詣?dòng)執(zhí)行持續(xù)監(jiān)控的過程，以確保 Git 存儲(chǔ)庫中配置的所需狀態(tài)與 Kubernetes 集群中的實(shí)際狀態(tài)相匹配。 一旦它們?cè)诖鎯?chǔ)庫的聲明狀態(tài)中正確提交，就會(huì)用于協(xié)調(diào)和完成部署。

審計(jì)控制

GitOps 提供的審計(jì)功能也是 DevSecOps 支持的關(guān)鍵。 通過保留在 Git 存儲(chǔ)庫中作為單一事實(shí)來源，所有應(yīng)用程序、代碼和配置都進(jìn)行了版本控制，并保留了完整的審計(jì)跟蹤，這是任何安全環(huán)境的主要要求。此審計(jì)跟蹤通常也可供開發(fā)人員和運(yùn)營團(tuán)隊(duì)成員使用，以便他們觀察集群中正在運(yùn)行的內(nèi)容(大多數(shù)用戶僅限于只讀訪問集群配置)。

開發(fā)人員不一定需要像運(yùn)營和 DevSecOps 團(tuán)隊(duì)成員那樣依賴審計(jì)跟蹤，但他們可以利用這種能力來了解發(fā)生了哪些變化以及對(duì)存儲(chǔ)庫進(jìn)行更改的動(dòng)機(jī)是什么。簡而言之，對(duì)于開發(fā)人員 (以及所有 DevOps 團(tuán)隊(duì)成員)一切都只是一個(gè) Git 日志的問題。

Git 上的審計(jì)跟蹤也可供開發(fā)人員在需要時(shí)輕松查找。這是因?yàn)橄到y(tǒng)的完整歷史記錄在 Git 記錄系統(tǒng)中，開發(fā)人員可以理解這一點(diǎn)。

借助審計(jì)跟蹤的可用性，開發(fā)人員還可以輕松回滾導(dǎo)致問題的應(yīng)用程序的更改。 當(dāng)集群遭到破壞或配置錯(cuò)誤時(shí)，這尤其有用。 在這種情況下，審計(jì)跟蹤無需從頭開始重建集群，而是在存儲(chǔ)庫中包含所需的狀態(tài)， 然后部署具有審計(jì)跟蹤所需狀態(tài)的集群配置和應(yīng)用程序，并自動(dòng)重建過程。

很少有“萬能鑰匙”

開發(fā)人員通常依靠 Jenkins(一種自動(dòng)化服務(wù)器)來構(gòu)建、測(cè)試和支持用于 Kubernetes 環(huán)境生產(chǎn)管道的 CI/CD。如果沒有 GitOps，開發(fā)人員在直接部署代碼時(shí)可能會(huì)直接訪問 Kubernetes 集群。換句話說，無論他們屬于組織內(nèi)部還是作為遠(yuǎn)程工作的承包商，這對(duì)開發(fā)人員來說可謂有了一把直接訪問生產(chǎn)環(huán)境的“萬能鑰匙”，但這不是一個(gè)理想的安全方案。

在上述情況下，只要錯(cuò)誤的用戶(或更糟糕的入侵者)使用 KubeConfig 或 Kubectl 命令訪問生產(chǎn)環(huán)境中的集群，這些集群就可以從筆記本電腦上訪問。如果攻擊者破壞了 CI 系統(tǒng)和憑據(jù)集，那么他們還可以訪問 CI 系統(tǒng)有權(quán)訪問的任何群集。

GitOps 有助于防止用戶(或攻擊者)在不留下任何痕跡的情況下更改群集配置，這一點(diǎn)對(duì)于運(yùn)營和安全團(tuán)隊(duì)尤其重要，此外還有助于減輕開發(fā)人員的心理負(fù)擔(dān)。例如，通過訪問控制，開發(fā)人員通常不應(yīng)該直接訪問 Kubernetes 節(jié)點(diǎn)和/或 kubectl 命令行。因此，GitOps 可以協(xié)調(diào)開發(fā)人員在 Git 中定義的任何內(nèi)容，但除非開發(fā)人員具有特殊的訪問控制權(quán)限，否則不允許手動(dòng)訪問 Kubernetes 集群或生產(chǎn)環(huán)境。

GitOps 的 DevSecOps 功能是阻止 CD 攻擊媒介場(chǎng)景的一種方式，從而保護(hù)這把"萬能鑰匙"。當(dāng)GitOps運(yùn)算符(如開源 Flux，下面將對(duì)此進(jìn)行詳細(xì)介紹)在 Kubernetes 內(nèi)部運(yùn)行時(shí)，可以訪問集群，訪問控制仍保留在 Kubernetes 安全框架中。用戶訪問權(quán)限是通過向不同團(tuán)隊(duì)和團(tuán)隊(duì)成員的命名空間分配權(quán)限來確定的。

美國國防部(DoD)提供了一個(gè)有效利用DevSecOps和GitOps 的例子。最近，美國空軍首席軟件官尼古拉斯·查蘭(Nicolas Chaillan)講述了DevSecOps和GitOps如何與Flux一起在支持整個(gè)美國空軍保安部隊(duì)的軟件開發(fā)中發(fā)揮了關(guān)鍵作用。

查蘭表示，“安全和保障是不可讓步的問題，但我們也希望開發(fā)人員能通過自助服務(wù)提高生產(chǎn)力并加快速度?！?/p>

美國國防部表示，GitOps是“在整個(gè)國防部成功構(gòu)建和推出‘平臺(tái)一號(hào)’(Platform One)的關(guān)鍵”。平臺(tái)一號(hào)是“一個(gè)經(jīng)過批準(zhǔn)，完全與云原生計(jì)算基金會(huì)(CNCF)的Kubernetes發(fā)行版兼容，同時(shí)還有基礎(chǔ)設(shè)施即代碼的劇本以及強(qiáng)化容器的集合"，具有內(nèi)置的安全管道。

制衡

DevSecOps 流程與 GitOps 集成，提供制衡。因?yàn)樗欣≌?qǐng)求都經(jīng)過評(píng)審，所以通過這種方式，它提供的訪問控制可以防止開發(fā)人員或入侵者訪問源代碼存儲(chǔ)庫，從而在CI過程中引入后門，零日漏洞或其他類型的漏洞。

由于 DevSecOps 支持 CI 進(jìn)程，因此在 Git 上提交代碼并部署在群集中之前就已進(jìn)行檢查和平衡。開發(fā)人員通常會(huì)將更改作為拉取請(qǐng)求提交，該請(qǐng)求會(huì)經(jīng)過評(píng)審。一旦經(jīng)過審查和批準(zhǔn)，代碼就會(huì)合并到 Git 上，然后相應(yīng)地更改所需狀態(tài)的 YAML 文件。

所需的狀態(tài)將自動(dòng)應(yīng)用于 Kubernetes 集群。如上所述，具有 DevSecOps 功能的適當(dāng) GitOps 工具會(huì)持續(xù)監(jiān)控目標(biāo)系統(tǒng)內(nèi)的實(shí)際狀態(tài)，以確保它響應(yīng) Git 上聲明的內(nèi)容。如果有任何差異，則會(huì)發(fā)出警報(bào)，因此可以采取糾正措施。

DevSecOps 自成一派

許多GitOps工具都支持DevSecOps。例如，開源 Flux 有助于維護(hù) Git 存儲(chǔ)庫，使其成為單一不可變的事實(shí)來源。Flux 的功能還擴(kuò)展到訪問控制，以便在 CI/CD 期間對(duì)提交和部署的代碼進(jìn)行檢查和平衡。

對(duì)于更有個(gè)性的 Flux 體驗(yàn)，開源 Weave GitOps Core 讓幫助跨多個(gè)集群自動(dòng)化 CI/CD的起始步驟更簡化。此外，使用Weave GitOps Core設(shè)置GitOps和DevSecOps的過程涉及控制臺(tái)上的一些簡單命令。

Weave GitOps Enterprise 已成為第一個(gè) GitOps 平臺(tái)，該平臺(tái)可在任何規(guī)模的混合云、多云和邊緣架構(gòu)中為 Kubernetes 自動(dòng)執(zhí)行持續(xù)應(yīng)用程序交付和自動(dòng)化運(yùn)營控制。

所有這三個(gè)工具都有助于自動(dòng)執(zhí)行監(jiān)控，以確保群集配置始終與 Git 上的內(nèi)容匹配，從而幫助防止漂移。完整且可訪問的審計(jì)跟蹤允許根據(jù)需要回滾應(yīng)用程序和群集配置，而無需從頭開始重建群集。

總而言之，GitOps代表了分布式Kubernetes環(huán)境的DevOps的演變，而在整個(gè)應(yīng)用程序生命周期中，DevSecOps已成為維護(hù)GitOps的CI / CD安全性的重要方式。

譯者介紹

朱鋼，51CTO社區(qū)編輯，2021年IT影響力專家博主，阿里云專家博主，2019年CSDN博客之星20強(qiáng)，2020年騰訊云+社區(qū)優(yōu)秀作者，11年一線開發(fā)經(jīng)驗(yàn)，曾參與獵頭服務(wù)網(wǎng)站架構(gòu)設(shè)計(jì)，企業(yè)智能客服以及大型電子政務(wù)系統(tǒng)開發(fā)，主導(dǎo)某大型央企內(nèi)部防泄密和電子文檔安全監(jiān)控系統(tǒng)的建設(shè)，目前在北京圖伽健康從事醫(yī)療軟件研發(fā)工作。

原文標(biāo)題：??Why GitOps is crucial for DevSecOps??，作者：Steve Waterworth