紅帽了一份最新的「2022 年 Kubernetes 安全狀況」報告，調查了組織在雲原生開發方面面臨的安全挑戰，以及他們如何應對這些挑戰以保護其應用程式和 IT 環境。該報告基於對 300 多名 DevOps、工程和安全專業人員的調查，重點介紹了公司如何在採用容器和 Kubernetes 的同時平衡這些環境的安全性。
報告指出，與前幾年類似，安全仍然是容器採用的最大問題之一。新技術與傳統 IT 環境整合時可能會帶來無法預料的安全挑戰，而鑑於容器的安全需求橫跨應用程式生命週期的所有方面，從開發到部署和維護，容器呈現出特別複雜的情況。該報告發現，31% 的受訪者對容器策略最常見的擔憂是對容器的安全威脅和容器安全投資不足。
有 93% 的受訪者在過去 12 個月中在其 Kubernetes 環境中至少經歷過一次安全事件，該事件有時也導致了受訪者收入或客戶的流失。過去一年，超過一半的受訪者（55%）還因為安全問題不得不推遲他們應用程式的推出。對此，報告將責任歸咎於 Kubernetes 主要是專注於生產力而不是安全性。「Kubernetes 和容器雖然功能強大，但卻是為開發者的生產力而設計的，不一定是為了安全。例如，預設的 pod-to-pod 網路設定允許開放通訊，以快速啟動和執行一個叢集，但卻犧牲了安全加固。」
報告稱，人為錯誤仍然是導致資料洩露的原因之一；其參照了世界經濟論壇的進行佐證，「人為錯誤是 95% 的資料洩露事件的主要促成因素」。資料表明，在過去的 12 個月裡，近 53% 的受訪者在他們的環境中經歷了錯誤設定事件。38% 的人發現了一個重大的漏洞，30% 的人說他們遭遇了執行時安全事件；還有 22% 的人說他們沒有通過審計。
相較於媒體廣泛關注的網路攻擊，IT 人員最為擔心的也還是錯誤設定所造成的風險。「Kubernetes 是高度可客製化的，具有可以影響應用程式安全狀態的各種設定選項。因此，受訪者最擔心由於容器和 Kubernetes 環境中的錯誤設定而導致的風險（46%）—— 幾乎是對攻擊的擔憂程度（16%）的三倍」。儘可能的自動化設定管理則有助於緩解這些問題。
另一方面，DevSecOps 已逐漸成為一些組織的標準。絕大多數受訪者（78%）表示，他們在初級或高階階段都有 DevSecOps 計劃。在 DevSecOps 方面，27% 的受訪者認為自己所在的是最具前瞻性的組織，他們採用先進的 DevSecOps 計劃，在整個應用程式生命週期中整合和自動化安全性。
開發、運維和安全團隊之間的共同作業也被重視起來。報告指出，受當今快速的釋出週期影響，安全性已經必須左移並嵌入到 DevOps 工作流中，而不是在應用程式即將部署到生產中時才考慮；大部分受訪者都對這一觀點表示了認同。除了很多人正在實施 DevSecOps 之外，只有 22% 的受訪者表示他們繼續將 DevOps 與安全分開操作；且只有 16% 的受訪者確定他們將由中央 IT 安全團隊負責 Kubernetes 的安全。
紅帽方面總結稱，儘管存在潛在的安全問題，但採用容器和 Kubernetes 的好處仍然大於弊端。關鍵是尋找一個容器和 Kubernetes 安全平臺，將 DevOps 最佳實踐和內部控制作為其設定檢查的一部分。它還應該評估 Kubernetes 本身的設定的安全狀況，以便開發人員可以專注於功能交付。