建站
咨詢
售后
建站咨詢
新聞中心
譯者 | 朱鋼
創(chuàng)新互聯(lián)公司致力于互聯(lián)網(wǎng)網(wǎng)站建設(shè)與網(wǎng)站營銷，提供網(wǎng)站設(shè)計、做網(wǎng)站、網(wǎng)站開發(fā)、seo優(yōu)化、網(wǎng)站排名、互聯(lián)網(wǎng)營銷、小程序定制開發(fā)、公眾號商城、等建站開發(fā)，創(chuàng)新互聯(lián)公司網(wǎng)站建設(shè)策劃專家，為不同類型的客戶提供良好的互聯(lián)網(wǎng)應用定制解決方案，幫助客戶在新的全球化互聯(lián)網(wǎng)環(huán)境中保持優(yōu)勢。
審校 | 梁策 孫淑娟
DevOps在自動化、可追溯性方面的優(yōu)勢已得到廣泛認可，此外它還能助力從前孤立的團隊和利益相關(guān)者展開協(xié)作。但是，隨著 DevOps 團隊越來越多地承擔將運營轉(zhuǎn)移到容器化的Kubernetes 環(huán)境的任務，久經(jīng)考驗的 DevOps 實踐也可能棋差一著。如今，安全和風險問題正以不同的方式表現(xiàn)出來。
好消息是，在分布式環(huán)境的安全方面，GitOps 填補了 DevOps 中的許多空白。 由于GitOps 流程非常有利于 DevSecOps，此處定義為適用于整個應用程序生命周期的安全最佳實踐。
在本文中，我們將了解 GitOps 如何為 DevSecOps 提供基本框架，在整個 CI/CD 以及 Kubernetes 集群上應用程序管理部署后的階段進行安全檢查。
單一不變的事實來源
GitOps 可以定義為：
Kubernetes 和其他云原生技術(shù)的運營模型，它提供一組最佳實踐，統(tǒng)一容器化集群和應用程序的 Git 部署、管理和監(jiān)控。
它是實現(xiàn)開發(fā)人員管理應用程序經(jīng)驗的途徑;其中，端到端 CI/CD 管道和 Git 工作流應用于運營和開發(fā)。
正如此處聲明了所需的配置， Git 是單一的事實來源。 Kubernetes 內(nèi)部運行了一個 GitOps 代理，它不斷將 Kubernetes 內(nèi)部的實際狀態(tài)與存儲在 Git 中的所需狀態(tài)進行比較。 任何合并到 Git 中受監(jiān)控分支的新更改都會自動應用于 Kubernetes。 相反，任何直接應用于 Kubernetes 的手動更改都會自動恢復到 Git 中聲明的所需狀態(tài)。配置漂移得到了消除。
由于其不可變的結(jié)構(gòu)，Git 通常被描述為適用于 GitOps 的單一事實來源。除其他事項外，它還有助于維護一個邊界(與防火墻不同)，該邊界將 CI 和 CD 之間的問題分開。通過這種方式，作為CI的一部分，應用程序開發(fā)中涉及的步驟數(shù)量(拉取請求，測試，提交等) 在Git上保持獨立。
對于提出拉取請求的開發(fā)人員，拉取請求在審查和批準后會被合并，并在下一次協(xié)調(diào)時自動應用于集群(一般需要 15 分鐘)。
默認情況下，該過程是雙向的——這意味著當下一個協(xié)調(diào)循環(huán)運行時(通常每 15 分鐘一次)，直接對 Kubernetes 所做的更改會在 Git 上得到響應。但是，當 DevOps 團隊成員或非法行為入侵者直接對集群進行更改時，這種情況并不理想。這些直接到集群的更改沒有通過合并請求和批準，因此違反了 GitOps 原則，即當發(fā)生漂移時 Git 作為不可變的事實來源。
作為一種幫助減少漂移發(fā)生的解決方案，GitOps 監(jiān)控工具可以在對集群作出更改而未先在 Git 中應用時發(fā)送警報。當這種情況發(fā)生時，由于審計跟蹤，通過運行時環(huán)境中處于部署狀態(tài)的控制器，Git 上的應用程序代碼可以替換對集群所做的錯誤更改。
相反，如果不變性沒有實現(xiàn)，就會發(fā)生漂移。這可能在網(wǎng)絡(luò)攻擊的情況下發(fā)生，或 DevOps 團隊成員無意更改了集群配置，使其與 Git 上的配置不同。出現(xiàn)這種情況時，使用適當?shù)?GitOps 工具能夠?qū)⒉灰恢聵擞洺鰜?，從而代?GitOps 流程提供的典型 DevSecOps。
適當?shù)墓ぞ呖梢宰詣訄?zhí)行持續(xù)監(jiān)控的過程，以確保 Git 存儲庫中配置的所需狀態(tài)與 Kubernetes 集群中的實際狀態(tài)相匹配。 一旦它們在存儲庫的聲明狀態(tài)中正確提交，就會用于協(xié)調(diào)和完成部署。
審計控制
GitOps 提供的審計功能也是 DevSecOps 支持的關(guān)鍵。 通過保留在 Git 存儲庫中作為單一事實來源，所有應用程序、代碼和配置都進行了版本控制，并保留了完整的審計跟蹤，這是任何安全環(huán)境的主要要求。此審計跟蹤通常也可供開發(fā)人員和運營團隊成員使用，以便他們觀察集群中正在運行的內(nèi)容(大多數(shù)用戶僅限于只讀訪問集群配置)。
開發(fā)人員不一定需要像運營和 DevSecOps 團隊成員那樣依賴審計跟蹤，但他們可以利用這種能力來了解發(fā)生了哪些變化以及對存儲庫進行更改的動機是什么。簡而言之，對于開發(fā)人員 (以及所有 DevOps 團隊成員)一切都只是一個 Git 日志的問題。
Git 上的審計跟蹤也可供開發(fā)人員在需要時輕松查找。這是因為系統(tǒng)的完整歷史記錄在 Git 記錄系統(tǒng)中，開發(fā)人員可以理解這一點。
借助審計跟蹤的可用性，開發(fā)人員還可以輕松回滾導致問題的應用程序的更改。 當集群遭到破壞或配置錯誤時，這尤其有用。 在這種情況下，審計跟蹤無需從頭開始重建集群，而是在存儲庫中包含所需的狀態(tài)， 然后部署具有審計跟蹤所需狀態(tài)的集群配置和應用程序，并自動重建過程。
很少有“萬能鑰匙”
開發(fā)人員通常依靠 Jenkins(一種自動化服務器)來構(gòu)建、測試和支持用于 Kubernetes 環(huán)境生產(chǎn)管道的 CI/CD。如果沒有 GitOps，開發(fā)人員在直接部署代碼時可能會直接訪問 Kubernetes 集群。換句話說，無論他們屬于組織內(nèi)部還是作為遠程工作的承包商，這對開發(fā)人員來說可謂有了一把直接訪問生產(chǎn)環(huán)境的“萬能鑰匙”，但這不是一個理想的安全方案。
在上述情況下，只要錯誤的用戶(或更糟糕的入侵者)使用 KubeConfig 或 Kubectl 命令訪問生產(chǎn)環(huán)境中的集群，這些集群就可以從筆記本電腦上訪問。如果攻擊者破壞了 CI 系統(tǒng)和憑據(jù)集，那么他們還可以訪問 CI 系統(tǒng)有權(quán)訪問的任何群集。
GitOps 有助于防止用戶(或攻擊者)在不留下任何痕跡的情況下更改群集配置，這一點對于運營和安全團隊尤其重要，此外還有助于減輕開發(fā)人員的心理負擔。例如，通過訪問控制，開發(fā)人員通常不應該直接訪問 Kubernetes 節(jié)點和/或 kubectl 命令行。因此，GitOps 可以協(xié)調(diào)開發(fā)人員在 Git 中定義的任何內(nèi)容，但除非開發(fā)人員具有特殊的訪問控制權(quán)限，否則不允許手動訪問 Kubernetes 集群或生產(chǎn)環(huán)境。
GitOps 的 DevSecOps 功能是阻止 CD 攻擊媒介場景的一種方式，從而保護這把"萬能鑰匙"。當GitOps運算符(如開源 Flux，下面將對此進行詳細介紹)在 Kubernetes 內(nèi)部運行時，可以訪問集群，訪問控制仍保留在 Kubernetes 安全框架中。用戶訪問權(quán)限是通過向不同團隊和團隊成員的命名空間分配權(quán)限來確定的。
美國國防部(DoD)提供了一個有效利用DevSecOps和GitOps 的例子。最近，美國空軍首席軟件官尼古拉斯·查蘭(Nicolas Chaillan)講述了DevSecOps和GitOps如何與Flux一起在支持整個美國空軍保安部隊的軟件開發(fā)中發(fā)揮了關(guān)鍵作用。
查蘭表示，“安全和保障是不可讓步的問題，但我們也希望開發(fā)人員能通過自助服務提高生產(chǎn)力并加快速度?！?/p>
美國國防部表示，GitOps是“在整個國防部成功構(gòu)建和推出‘平臺一號’(Platform One)的關(guān)鍵”。平臺一號是“一個經(jīng)過批準，完全與云原生計算基金會(CNCF)的Kubernetes發(fā)行版兼容，同時還有基礎(chǔ)設(shè)施即代碼的劇本以及強化容器的集合"，具有內(nèi)置的安全管道。
制衡
DevSecOps 流程與 GitOps 集成，提供制衡。因為所有拉取請求都經(jīng)過評審，所以通過這種方式，它提供的訪問控制可以防止開發(fā)人員或入侵者訪問源代碼存儲庫，從而在CI過程中引入后門，零日漏洞或其他類型的漏洞。
由于 DevSecOps 支持 CI 進程，因此在 Git 上提交代碼并部署在群集中之前就已進行檢查和平衡。開發(fā)人員通常會將更改作為拉取請求提交，該請求會經(jīng)過評審。一旦經(jīng)過審查和批準，代碼就會合并到 Git 上，然后相應地更改所需狀態(tài)的 YAML 文件。
所需的狀態(tài)將自動應用于 Kubernetes 集群。如上所述，具有 DevSecOps 功能的適當 GitOps 工具會持續(xù)監(jiān)控目標系統(tǒng)內(nèi)的實際狀態(tài)，以確保它響應 Git 上聲明的內(nèi)容。如果有任何差異，則會發(fā)出警報，因此可以采取糾正措施。
DevSecOps 自成一派
許多GitOps工具都支持DevSecOps。例如，開源 Flux 有助于維護 Git 存儲庫，使其成為單一不可變的事實來源。Flux 的功能還擴展到訪問控制，以便在 CI/CD 期間對提交和部署的代碼進行檢查和平衡。
對于更有個性的 Flux 體驗，開源 Weave GitOps Core 讓幫助跨多個集群自動化 CI/CD的起始步驟更簡化。此外，使用Weave GitOps Core設(shè)置GitOps和DevSecOps的過程涉及控制臺上的一些簡單命令。
Weave GitOps Enterprise 已成為第一個 GitOps 平臺，該平臺可在任何規(guī)模的混合云、多云和邊緣架構(gòu)中為 Kubernetes 自動執(zhí)行持續(xù)應用程序交付和自動化運營控制。
所有這三個工具都有助于自動執(zhí)行監(jiān)控，以確保群集配置始終與 Git 上的內(nèi)容匹配，從而幫助防止漂移。完整且可訪問的審計跟蹤允許根據(jù)需要回滾應用程序和群集配置，而無需從頭開始重建群集。
總而言之，GitOps代表了分布式Kubernetes環(huán)境的DevOps的演變，而在整個應用程序生命周期中，DevSecOps已成為維護GitOps的CI / CD安全性的重要方式。
文章標題：為什么GitOps對DevSecOps至關(guān)重要
文章轉(zhuǎn)載：http://www.5511xx.com/article/dpjpdsd.html
