《紅帽:2022年Kubernetes安全狀況報告(21頁).pdf》由會員分享,可在線閱讀,更多相關《紅帽:2022年Kubernetes安全狀況報告(21頁).pdf(21頁珍藏版)》請在三個皮匠報告上搜索。
1、Kubernetes 安全狀況報告2022 年1執行摘要執行摘要最新版 Kubernetes 安全狀況報告分析了容器、Kubernetes 和云原生安全方面的新趨勢。報告重點介紹了云原生開發中的安全挑戰,以及企業如何解決這些挑戰并保護自己的應用。該報告根據來自 300 多名開發運維(DevOps)、工程和安全專家的調查結果,揭示了有關采用容器和 Kubernetes 的各公司為保護其云原生環境而實施“開發、安全和運維”(DevSecOps)計劃的新發現。安全性是在容器采用方面最擔憂的問題之一,安全問題仍在導致應用部署到生產時出現延遲。我們也調查了公司在 Kubernetes 環境中遇到的最常見
2、安全事件類型,以及他們是否報告了這些事件所導致的客戶或營收損失。DevSecOps 正在快速成為在 DevOps 工作流中盡早進行安全測試和解決安全問題的一項標準,超過 3/4 的受訪者制定了旨在改善 DevOps 和安全團隊之間協作的計劃。調查結果突出了開發、運維和安全團隊就實現安全性在開發生命周期早期合作的重要性,從而實現 Kubernetes 的最大優勢快速創新。我們鼓勵您根據本報告中的發現進行自我基準測試,以確定如何進行跨容器和 Kubernetes 應用安全控制。安全防護延誤可能導致創新的延誤或面臨財務損失。您可以利用容器和 Kubernetes 中的許多安全性有利因素聲明性配置、不
3、可變基礎框架以及容器化應用中的固有隔離。然而,公司需要知識、工具和流程來使這些功能發揮作用,以保證其能在由 DevOps 驅動、云原生的世界中快速運行這一巨大優勢中受益。執行摘要關鍵解讀安全問題混合云部署安全防護用例開源安全防護工具安全性改進提示關于受訪者紅帽 Kubernetes 高級集群安全執行摘要關鍵解讀53%的受訪者在過去 12 個月內檢測到 Kubernetes 配置錯誤51%的受訪者要求開發人員使用經驗證的鏡像43%的受訪者將“DevOps”視為負責保護 Kubernetes 安全的角色57%的受訪者最擔心運行時的工作負載防護78%的受訪者擁有新人入門或高級階段的 DevSecOp
4、s 計劃55%的受訪者由于安全問題延后或推遲了應用部署安全性是容器采用方面的最大擔憂之一,安全問題仍在導致應用部署到生產時出現延遲。執行摘要關鍵解讀安全問題混合云部署安全防護用例開源安全防護工具安全性改進提示關于受訪者紅帽 Kubernetes 高級集群安全3安全問題安全問題阻礙創新大多數受訪者都曾由于安全問題未解決而導致應用交付推遲。企業正在通過采用 Kubernetes 和微服務應用架構等云原生技術,轉變他們構建、運行和擴展應用的方式。一些企業將所有新應用構建為微服務,另一些企業在兼顧重構現有應用的同時,對單體式應用進行管理。他們還必須轉變在云原生堆棧中實施安全防護的方式。發布周期更短、錯
5、誤修復更快,以及靈活性更強以在不同混合環境之間運行和管理應用,是容器化最常提及的三大優勢。然而,當安全防護成為事后補救措施時,您可能會忽視容器化所帶來的最大收益敏捷性。多數受訪者(55%)在過去 12 個月中,不得不因為安全問題而推遲應用推出。新技術常常會帶來不可預見的安全挑戰。一些企業在安全需求方面不堪重負,這些需求覆蓋從開發到部署和維護整個應用生命周期的所有層面。他們需要一種簡便的方法,不僅能夠保護容器化應用,并且不會減慢開發速度或增加運維復雜性。您是否曾因為容器或 Kubernetes 安全問題而延后或推遲將應用部署生產?55%是45%否內容摘要安全問題阻礙創新容器策略責任依舊分散Dev
6、SecOps 得到大規模采用配置不當是首要問題混合云部署安全防護用例開源安全防護工具安全性改進提示關于受訪者紅帽 Kubernetes 高級集群安全4安全問題在過去 12 個月內,93%的受訪者在 Kubernetes 環境中至少遇到過一次安全事件,這些安全事件有時也造成了營收或客戶損失。在過去 12 個月內,93%的受訪者在 Kubernetes 和容器環境中遇到過安全事件。這背后綜合了諸多因素,如缺乏關于容器和 Kubernetes 的知識、采用不適當或不匹配的安全防護工具,以及中央安全團隊跟不上快速移動的應用開發團隊的步伐等。結果是,31%的受訪者表示,過去 12 個月里曾經因為安全事件
7、而造成營收或客戶損失。人為錯誤依舊是數據泄露的首要原因。近期的一項研究表明,95%的數據泄露中人為錯誤是首要影響因素。Kubernetes 和容器盡管功能強大,但設計面向的是開發人員生產力,未必重視安全性。例如,默認的容器集間網絡設置允許開放式通信,以損失安全強化為代價,讓集群快速準備就緒并上線運行。近 53%的受訪者過去 12 個月在其環境中遇到過配置錯誤事件,這個結果并不出人意料。38%的受訪者發現了重大漏洞,而 30%的受訪者則表示他們在運行時遇到了安全事件。最后,22%的受訪者表示沒有通過審核。1.世界經濟論壇,“2022 年全球風險報告”,2022 年 1 月。在過去 12 個月中,
8、您是否遇到過與容器/Kubernetes 安全性或合規問題/事件相關的營收/客戶損失?53%檢測到配置錯誤38%需要修復重大漏洞30%發生運行時安全事件22%未通過審核7%無在過去 12 個月中,您遇到過哪些與容器和/或 Kubernetes 相關的安全事件或問題?(可多選)69%否31%是內容摘要安全問題阻礙創新容器策略責任依舊分散DevSecOps 得到大規模采用配置不當是首要問題混合云部署安全防護用例開源安全防護工具安全性改進提示關于受訪者紅帽 Kubernetes 高級集群安全5安全問題安全性是容器策略中的首要問題之一鑒于我們更早的調查結果突顯了這些環境中安全事件的普遍性(93%),安
9、全性仍然是容器策略的首要問題這一點也就不足為奇了??偠灾?,容器安全威脅相關問題(14%)和容器安全投入欠缺(17%)表明安全性(31%)是容器策略的首要問題。另有 22%的受訪者表示進展緩慢是他們最大的問題,而還有 20%受訪者則認為技能缺口是他們最大的問題。企業積極采用容器和 Kubernetes,投入云原生生態系統,以促進創新和發展。如果不能同時對安全策略和工具進行必要投資,其關鍵應用將面臨安全風險,甚至可能導致應用推出延誤。您公司容器策略最大的擔憂是什么?14%沒有嚴肅對待對容器的威脅6%未考慮合規性需求12%未考慮文化或流程變更內容摘要安全問題阻礙創新容器策略責任依舊分散DevSec
10、Ops 得到大規模采用配置不當是首要問題混合云部署安全防護用例開源安全防護工具安全性改進提示關于受訪者紅帽 Kubernetes 高級集群安全22%進展過于緩慢20%未解決團隊的技能缺口17%容器安全投資不足9%其他6安全問題Kubernetes 的安全職責仍然不夠集中,由 DevOps 主導在各種角色中,受訪者大多認為由 DevOps 負責保護容器和 Kubernetes??偠灾?,高達 78%的受訪者認為 DevOps、運維和 DevSecOps 等各種運維人員是 Kubernetes 安全的主要負責人。只有 16%的受訪者明確指定由中央 IT 安全團隊負責保護 Kubernetes 安全
11、。對此,研究推動采用容器和 Kubernetes 的因素可以獲得一些解釋。為了推動二者的使用,通常會將 DevOps 作為影子 IT,繞開中央 IT 團隊監管,因此受訪者指定由 DevOps 負責保護這些技術的安全,也就不足為奇了。為了彌合差距,容器和 Kubernetes 安全工具必須促進不同團隊之間的密切協作從 DevSecOps 到運維,再到安全團隊而不是使可能困擾公司的團隊隔離永久存在。您公司中哪個角色主要負責容器和 Kubernetes 的安全?DevOpsDevSecOps安全運維開發人員43%19%16%16%6%內容摘要安全問題阻礙創新容器策略責任依舊分散DevSecOps 得
12、到大規模采用配置不當是首要問題混合云部署安全防護用例開源安全防護工具安全性改進提示關于受訪者紅帽 Kubernetes 高級集群安全7安全問題DevSecOps 得到大規模采用DevSecOps 得到了大多數人的接納,此術語包含允許將安全構建到應用開發生命周期中的流程和工具,而不是把安全作為一個單獨的流程。我們的調查發現了喜聞樂見的消息絕大多數受訪者表示他們正在開展某種形式的 DevSecOps 計劃。只有 22%的受訪者依舊將 DevOps 與安全性分開運作。27%的受訪者認為自己在 DevSecOps 方面最有遠見,制定了進階 DevSecOps 計劃,在整個生命周期中整合并自動執行安全防
13、護。您公司中是否擁有 DevSecOps 計劃?27%是50%是22%否27%是我們正處于后期階段,在整個生命周期中整合和自動執行安全防護50%是我們正處于早期階段,DevOps 和安全部門根據聯合政策和工作流展開協作22%否DevOps 與安全團隊仍然互相獨立,協作較少內容摘要安全問題阻礙創新容器策略責任依舊分散DevSecOps 得到大規模采用配置不當是首要問題混合云部署安全防護用例開源安全防護工具安全性改進提示關于受訪者紅帽 Kubernetes 高級集群安全8安全問題受訪者對配置不當的擔憂高于所有其他安全問題Kubernetes 是可以高度自定義的容器編排器,具有各種可以影響應用安全態
14、勢的配置選項。因此,受訪者最擔心“由于容器和 Kubernetes 環境配置不當而導致的風險”(46%),幾乎是“受到攻擊”(16%)的三倍。第二大擔憂因素則是“漏洞”(28%)。配置管理給安全從業者帶來了獨特且艱巨的挑戰。負責配置工作負載的人可能不了解 Kubeneretes 中各種設置的安全含義。雖然有大量工具可用于容器鏡像的漏洞掃描,但配置管理需要考慮更多因素,還有可能因企業和團隊不同而各不相同,具體取決于風險容忍水平和工作負載敏感程度。人們可能知道應該避免部署 Kubernetes 控制面板,但配置容器集的安全內容或實施 Kubernetes 基于角色的訪問權限控制(RBAC)僅僅是說
15、明團隊需要更多挑戰性設置的兩個實例。應對這一挑戰的最佳方式是盡可能實現配置管理的自動化,以便安全工具(而不是人員)提供保護,幫助開發人員和 DevOps 團隊更加安全地配置容器和 Kubernetes。在以下風險中,您最擔心的是哪個容器和 Kubernetes 環境?配置不當/暴露漏洞攻擊不合規46%28%16%9%內容摘要安全問題阻礙創新容器策略責任依舊分散DevSecOps 得到大規模采用配置不當是首要問題混合云部署安全防護用例開源安全防護工具安全性改進提示關于受訪者紅帽 Kubernetes 高級集群安全9安全問題57%的受訪者最擔心容器生命周期中的運行時階段運行時有時也稱為 Day 2
16、 運維或部署后階段,是企業最為擔心的容器生命周期階段。這種擔心似乎與直覺相悖,因為絕大多數受訪者認為配置不當是最大的安全風險來源,且發生配置不當的次數比任何其他類型的安全事件更為頻繁。然而,需要考慮到,運行時安全問題通常是由構建或部署階段的安全失誤(如配置不當)引起的。此外,只有應用在生產環境中運行時,才可能感受到構建或部署階段安全失誤的任何負面結果。事件響應是安全防護的一個重要方面,在運行時也更加復雜。最后,運行時發現的安全問題,其修復代價也更加高昂。綜合以上,就更容易理解運行時安全擔憂排名升高的原因了。內容摘要安全問題阻礙創新容器策略責任依舊分散DevSecOps 得到大規模采用配置不當是
17、首要問題混合云部署安全防護用例開源安全防護工具安全性改進提示關于受訪者紅帽 Kubernetes 高級集群安全10內容摘要安全問題混合云部署面向大型企業的策略紅帽 OpenShift安全防護用例開源安全防護工具安全性改進提示關于受訪者紅帽 Kubernetes 高級集群安全混合云部署大型企業首選混合云部署純云策略的討論熱度很高,但單云或多云提供商的實際部署與企業的規模高度相關。規模較大的企業(1,000 名員工以上)推崇采用混合方法來運行容器化應用(42%),而規模較小的企業則偏愛單云策略(46%)。雖然混合模式依舊是企業和其他大型組織的主導方法,它們需要一致的安全性和合規性。您在哪里運行容器
18、?我們的數據中心/本地21%29%42%8%27%46%23%4%云提供商混合(本地+云提供商)多個公共云多于 1,000 名員工少于 1,000 名員工11混合云部署紅帽 OpenShift,混合云部署的領導者由于混合云部署是大型企業中運行容器化應用最流行的模式,我們希望了解公司如何在混合模式下進行部署。所有在混合環境里運行容器化工作負載的受訪者中,有一半使用紅帽 OpenShift 管理他們的容器和 Kubernetes。公共云提供商的技術產品的熱門程度與平臺總體受歡迎程度曲線相似,受訪者中有 37%使用 AWS Outposts,24%使用 Google Anthos,另有 17%則使用
19、 Azure Arc。VMware 和 Oracle 的混合產品落后于同行,分別有 9%和 7%的受訪者使用。您是否使用任何解決方案進行混合和多云 Kubernetes 部署?(可多選)紅帽 OpenShiftAWS OutpostsGoogle Anthos客戶 Oracle Cloud50%37%24%7%17%Microsoft Azure ArcVMware Tanzu9%內容摘要安全問題混合云部署面向大型企業的策略紅帽 OpenShift安全防護用例開源安全防護工具安全性改進提示關于受訪者紅帽 Kubernetes 高級集群安全12安全防護用例Kubernetes 安全防護熱門用例K
20、ubernetes 安全防護用例橫跨整個應用開發生命周期,企業期待安全解決方案能夠在每個階段保護容器和 Kubernetes。這些功能涵蓋 DevOps 和安全活動,強調在容器和 Kubernetes 安全平臺中需要廣泛和深入的功能。如此高的比例還突出了這樣一個事實:保護 Kubernetes 和容器需要開發、運維和安全團隊的參與。受訪者認為運行時威脅檢測/響應、配置管理和鏡像掃描/漏洞管理是有待解決的三個最重要的 Kubernetes 安全防護用例,分別被 69%、68%和 65%的受訪者認為是“不可或缺”的功能。您會如何對以下 Kubernetes 安全功能重要性進行排序?運行時威脅檢測/
21、響應配置管理鏡像掃描/漏洞管理可視性合規網絡分段不可或缺錦上添花無足輕重69%26%6%68%65%27%29%5%6%60%36%4%55%39%5%53%42%5%內容摘要安全問題混合云部署安全防護用例開源安全防護工具安全性改進提示關于受訪者紅帽 Kubernetes 高級集群安全13開源安全防護工具Open Policy Agent(OPA)和 KubeLinter 是 Kubernetes 安全性方面使用最廣泛的兩個開源解決方案。除了商用 Kubernetes 安全產品外,受訪者也依賴多款開源安全工具來保護他們的云原生應用。KubeLinter 是面向 Kubernetes 的一款開源
22、 YAML 和 HELM Linter 工具,有 36%的受訪者使用了這款工具,而 29%表示他們使用 OPA 來保護 Kubernetes 安全??蛻艨梢赃x擇豐富的開源安全工具,我們的調查結果顯示,沒有哪款開源安全工具壟斷 Kubernetes 安全市場。近四分之一的受訪者也使用 Kube-bench、Kube-hunter 和 Falco。您將哪些開源工具用于 Kubernetes 安全?(可多選)KubeLinterOpen Policy Agent(OPA)Kube-benchKube-hunter36%29%24%19%19%FalcoTerrascan其他CheckovClaire
23、17%16%9%9%內容摘要安全問題混合云部署安全防護用例開源安全防護工具安全性改進提示關于受訪者紅帽 Kubernetes 高級集群安全14安全性改進提示改進安全性的 4 點提示 當安全性被忽視時,企業沒有確保構建、部署和管理云原生環境的安全性,從而將快速開發和發布應用這一核心優勢置于風險之中。我們的調查結果表明,構建和部署階段發生的情況對安全性有重要影響,企業中普遍存在配置不當和漏洞恰恰突顯了這一點。因此,安全必須提前細微地嵌入到 DevOps 工作流中,而不是在應用快要部署到生產中時才“匆忙啟動”。使用 Kubernetes 原生安全架構和控制。Kubernetes 原生安全使用該環境內
24、豐富的聲明性數據和原生控制,這提供了幾個關鍵的安全優勢。分析可用的 Kubernetes 聲明性數據可提高安全性,并可基于風險洞察配置管理、合規性、分段和 Kubernetes 特定漏洞。使用相同的基礎架構及其控制進行應用開發和安全防護,可減少學習曲線,并更快地支持分析和故障排除。它還能夠消除運營沖突,辦法是保證安全獲得與 Kubernetes 擴展到基礎設施相同的自動化和可擴展性有利條件。安全防護應當盡早啟動,并且覆蓋從構建/部署到運行時整個生命周期。長期以來,安全工作一直被視為一種業務阻礙,尤其是對開發人員和 DevOps 團隊來說,核心任務是快速交付代碼。有了容器和 Kubernetes
25、,安全工作應該成為業務加速器,幫助開發人員從源頭為其資產構建強大的安全性。尋找一個容器和 Kubernetes 安全平臺,該平臺應將 DevOps 最佳實踐和內部控制包含在配置檢查之中。還應評估 Kubernetes 本身安全態勢的配置,以便開發人員專注于功能交付。12內容摘要安全問題混合云部署安全防護用例開源安全防護工具安全性改進提示關于受訪者紅帽 Kubernetes 高級集群安全15安全性改進提示需要能夠在混合環境之間移植。由于大多數公司在本地和公共云環境中(有時在多個云中)部署容器,因此無論您的資產在哪里運行,都必須始終如一部署安全工具。Kubernetes 就是基石,讓它成為您的事實
26、來源、執行點以及通用能見度層,這樣您就擁有了一致的安全性。Kubernetes 托管服務可能會提高公司采用 Kubernetes 的效能,但要注意被鎖定于云提供商特定的程序和服務。在 DevOps 和安全團隊之間搭建橋梁,將開發人員轉變為安全防護用戶。鑒于大多數公司都希望 DevOps 運行容器安全平臺,安全工具必須能夠幫助橋接 DevOps 團隊和安全團隊。為了行之有效,平臺必須具有能在基于容器化的 Kubernetes 環境中正常工作的安全控制,還應適當評估風險。告訴開發人員修復通用漏洞評分系統(CVSS)分數為 7 或更高的所有 39 個已發現漏洞是低效的行動。幫助開發人員識別該漏洞暴露
27、的三個部署,并找出存在風險的原因,這才能大幅改善您的安全態勢。34內容摘要安全問題混合云部署安全防護用例開源安全防護工具安全性改進提示關于受訪者紅帽 Kubernetes 高級集群安全16關于受訪者關于受訪者Kubernetes 服務92%的受訪者使用 Kubernetes(87%用于生產工作負載),其中 Amazon EKS、紅帽 OpenShift 和自助式 Kubernetes 是三種最受歡迎的 Kubernetes 服務。您是否使用 Kubernetes 進行容器編排?您使用哪個 Kubernetes 平臺來協調容器?(可多選)您是否在 Kubernetes 上運行任何生產工作負載?5
28、0%Amazon EKS44%Kubernetes(自助式)29%紅帽 OpenShift28%Google GKE22%Azure AKS15%Rancher/SUSE7%VMware Tanzu6%IBM Cloud Kubernetes Service2%Mirantis Container Cloud1%D2IQ Kubernetes Platform87%是13%否92%是8%否內容摘要安全問題混合云部署安全防護用例開源安全防護工具安全性改進提示關于受訪者Kubernetes 服務常見痛點和邊緣部署技術產品核心統計數據紅帽 Kubernetes 高級集群安全17關于受訪者Kubern
29、etes 安全供應商常見痛點內部人才欠缺和誤報太多是市面上 Kubernetes 安全解決方案的最常見痛點。內容摘要安全問題混合云部署安全防護用例開源安全防護工具安全性改進提示關于受訪者Kubernetes 服務常見痛點和邊緣部署技術產品核心統計數據紅帽 Kubernetes 高級集群安全您當前 Kubernetes 安全解決方案的最大痛點是什么?(可多選)30%缺少內部人才,無法發揮其全部潛力27%沒有解決方案24%錯誤警報(警報疲勞)過多24%整個應用生命周期未得到保護20%太難使用,無法實施到我們的系統中19%安全產品過多17%不能應用于我們采用 Kubernetes 的所有環境中16%
30、減慢了開發速度7%未實現承諾的功能(霧件)邊緣部署將近半數受訪者在邊緣位置運行容器。49%是44%否7%我不知道18關于受訪者其他云原生數據除代碼存儲庫和容器鏡像倉庫外,新興云原生技術依舊處于早期采用階段。容器運行時技術Docker 運行時引擎仍然占主導地位,容器遠遠落后,但正在逐漸拉近距離。87%Docker36%容器17%CRI-O3%Kata 容器2%未知4%其他我不知道不感興趣正在調查正在試點生產6%4%4%14%15%代碼存儲庫容器鏡像倉庫Kubernetes 原生 CI/CD 工具(Tekton、Argo 等)無服務器功能即服務(Lambda、Azure Functions 等)服
31、務網格(Istio、Linkerd、Consul 等)Open Policy Agent(OPA)3%15%13%63%16%14%61%9%31%13%33%8%14%25%19%34%8%13%32%16%30%8%40%15%22%31%13%29%14%13%內容摘要安全問題混合云部署安全防護用例開源安全防護工具安全性改進提示關于受訪者Kubernetes 服務常見痛點和邊緣部署技術產品核心統計數據紅帽 Kubernetes 高級集群安全19關于受訪者核心統計數據行業8%教育1%娛樂18%金融服務/保險9%醫療保健5%制造3%媒體47%技術8%其他公司規模25%110026%1011,
32、00015%1,0015,00010%5,00110,00024%10,001+職能工作崗位21%安全10%合規/風險38%運維24%產品開發/工程8%其他21%10%38%24%8%25%26%15%10%24%8%8%18%9%5%3%47%1%內容摘要安全問題混合云部署安全防護用例開源安全防護工具安全性改進提示關于受訪者Kubernetes 服務常見痛點和邊緣部署技術產品核心統計數據紅帽 Kubernetes 高級集群安全20紅帽 Kubernetes 高級集群安全內容摘要安全問題混合云部署安全防護用例開源安全防護工具安全性改進提示關于受訪者紅帽 Kubernetes 高級集群安全進一步
33、了解用于 Kubernetes 的紅帽高級集群安全防護用于 Kubernetes 的紅帽高級集群安全防護是 Kubernetes 原生安全平臺,能夠在您使用容器的過程中保護您的應用進行構建、部署和運行。隨著環境更加依賴于自動化,我們的平臺將幫助您在越來越復雜的環境中實現安全性操作,跟上 DevOps 的速度。Kubernetes 原生安全具有以下關鍵優勢。最大限度地降低運營風險:使用 Kubernetes 原生控制來降低威脅并實施安全策略,從而最大限度地降低應用的運營風險,讓您的安全團隊與 DevOps 保持步調一致。降低運營成本:減少時間、精力和人員方面的總體投入,用共同的事實來源簡化安全分析、調查和修補。提高 DevOps 工作效率:為開發人員提供可操作且內容豐富的安全指示,并嵌入到現有的、可提高開發人員速度的工作流程和工具中,從而加快創新步伐。已準備好將紅帽 Kubernetes 高級集群安全運用于實踐?獲取針對您的業務和需求量身定制的個性化演示。獲取演示 2022 年紅帽版權所有。紅帽、紅帽企業 Linux、紅帽 logo 和 OpenShift 均為紅帽在美國和其他國家/地區的商標或注冊商標。Linux 是 Linus Torvalds 在美國和其他國家/地區的注冊商標。