“Kubernetes生態系統狀況”闡述了在選擇容器編排解決方案時不同標準的重要性，以及阻礙Kubernetes採用的主要因素。與安全性或資源優化等標準相比，擴充套件性成為編排解決方案的基本要求。其中最大的挑戰是，使用Kubernetes經常需要改變IT組織的幾個部分的角色或職責。

CNCF最近的調查詢問到人們在使用或部署容器時面臨的挑戰。在我們對資料的獨立分析中，我們將答案發布在“Kubernetes Deployment & Security Patterns”一文中，並將焦點集中於使用Kubernetes管理容器的組織。這提供了一種方法來說明Kubernetes使用者所面臨的問題。

研究結果表明，在對Kubernetes的普遍批評中，複雜性僅僅是排在第五位的挑戰。領先的是與基礎設施相關的挑戰。在Kubernetes使用者中，有46%的人提到了安全問題，網路和儲存排在第二和第三位。

KubeCon +CloudNativeCon會議召集了採用者和技術專家，進一步推進雲原生計算的教育和發展。供應商中立的技術有該領域專家和關鍵維護者的支援，比如Kubernetes, Prometheus, gRPC，Envoy，OpenTracing等等。

Twistlock利用先進的智慧，機器學習功能以及自動策略建立和執行功能，保護當今應用程式免受未來的威脅。作為第一個端到端的容器安全解決方案，Twistlock是專門為交付現代安全性而構建的。

Alcide提供網路安全平臺，專為由多個編排系統運營的容器、虛擬機器和裸金屬資料中心組合而設計。Alcide通過簡化和自動控制為DevOps，安全和工程團隊授權，以管理和保護不斷髮展的資料中心和混合雲。

23%的人表示，基於負載的擴充套件部署是一個挑戰。這意味著許多需求得到滿足Kubernetes實際上是在幫助擴充套件它應該做的事情。在列表的底部，10%的問題得到了供應商的支援。很少有人抱怨Kubernetes支援供應商的原因之一是，許多部署並不依賴於供應商的分銷。展望未來，提供高質量服務的可能性很大，因為CNCF最近推出了Kubernetes認證服務供應商計劃，確保服務提供商達到一定的能力。

超過40%的人認為安全、網路和儲存是與容器相關的挑戰。

和其他研究一樣，我們發現較大的組織更傾向於將許多問題列為他們所關心的挑戰。例如，1000名或更多員工的組織中，有55%的人認為安全是一個挑戰，而不到100名員工的組織中只有39%的人這麼認為。這種情況下，與可靠性等其他類別一樣，大型企業的需求與小企業不同。

在其他領域，例如網路，與僅使用容器數量相比，IT基礎設施(頻寬和站點數量)的規模和廣度可能會給Kubernetes帶來更多獨特的挑戰。事實上，在擁有6個或6個以上叢集的組織中，以網路作為挑戰的比例從42%上升到53%。

一些挑戰不符合上述模式。對於儲存，一種解釋是技術“問題”不是基於可擴充套件性的。在監管方面，中型企業更有可能面臨挑戰。正如我們之前在文章中提到的，對容器運營的監控，小企業通常不需要建立正式的監控流程，而大型企業則有資源來建立更健壯的、自定義的監視系統。被困在中間的是那些擁有100到999名員工的企業。

圖1.8:在擁有1000名或更多員工的組織中，安全與網路更大可能被列為與容器相關的挑戰。

影響組織與容器相關的挑戰的另一個因素是，它們是否只將容器部署到公有云或在本地伺服器上。在只使用本地伺服器的容器中，儲存是最常見的挑戰。這是因為這些企業需要管理自己的儲存基礎設施，甚至可能由一支獨立的IT團隊來處理。

圖1.9：54%僅供本地使用的容器使用者面臨儲存挑戰，而只有34%的公有云組織面臨儲存挑戰。

對於只在公有云上使用容器的組織來說，監控和日誌記錄常常被認為是一個挑戰。儘管雲供應商應該支援可擴充套件性，但只有使用本地伺服器才能使用容器的組織很難說擴充套件部署是一項挑戰。

CNCF的調查還詢問了幾種型別的雲原生基礎設施和工具，其中一些是專門針對與Kubernetes合作的。本系列的下一篇文章將討論Kubernetes使用者用來解決他們面臨的挑戰的最常用工具。

4種Kubernetes威脅模型

在Kubernetes環境中，通常有四種類型的威脅，不管部署模型是什麼(有一些邊界情況例外)：

1.旨在危害Kubernetes控制的外部攻擊：所有連線系統均存在此威脅。在Kubernetes叢集環境中，這代表攻擊者獲得對系統的訪問許可權，或者損害某些會影響系統安全的控制。

2.受影響的容器或節點：如果Kubernetes控制的環境中存在惡意容器或叢集內的惡意節點，那麼對其他節點或叢集有什麼影響？你能否在節點和叢集內有效地包含“爆炸半徑”？

3.妥協的憑證：當Kubernetes管理員的憑據被洩露時會發生什麼情況？這對叢集有多大影響？

4.濫用合法許可權：當系統配置錯誤，缺乏控制或操作不嚴密時，可能會發生這種情況。

這些不同的威脅可能會導致大量妥協和不受歡迎的情況，包括特權提升，敏感資料洩露，運營折中或違反合規政策。

KubeCon + CloudNativeCon會議聚集了採用者和技術專家，進一步推動雲原生計算的教育和發展。供應商中立的特色領域由領域專家和關鍵維護者的支援，如Kubernetes，Prometheus, gRPC，Envoy,OpenTracing等等。

引起相當多關注的攻擊場景之一是“爆炸半徑”——受損容器對同一節點上的其他容器會造成多大的損害，或者受損的節點會對叢集的其餘部分造成多大的損害? 對於Kubernetes部署的所有安全考慮都是基於這些威脅模型以及最小化“爆炸半徑”的需要。

在Kubernetes環境中，外部可訪問的元件將受到外部攻擊。這些元件可以包括API伺服器、kubelet和etcd。

為了減輕外部攻擊的威脅，確保只有必要的Kubernetes服務被公開。始終執行身份驗證併為任何公開的服務配置正確的網路安全策略。

最終，Kubernetes管理在容器中執行的工作負載。如果一個容器被破壞，問題是容器是否可以升級許可權來控制其他容器或叢集。

Kubernetes的隔離機制，比如名稱空間或網路分割，以及一些內建的os級控制，調節容器可以訪問的內容，可以幫助限制受影響的容器的影響。另一個控制使用者應該注意的是限制能夠以特權模式執行的容器數量的能力——如果一個特權容器被破壞，它將會比普通的容器造成更多的傷害。

當合法的使用者憑證被破壞時，系統中可能有惡意使用者。因此，正確地規範和限制使用者對叢集資源的訪問並密切監視使用者操作是非常重要的。

為了減少惡意使用者的影響，需要強制執行最小許可權訪問、基於角色的訪問控制或其他細粒度訪問控制。

如果系統配置不正確，可能導致濫用使用者許可權。例如，如果網路策略不限制pods或名稱空間之間訪問，使用者可能能夠讀取其他名稱空間的通訊流，而這些名稱空間最初不應訪問。

防止濫用特權的主要防禦措施是適當強化。確保所有系統元件（如容器，pod，名稱空間和kubelets）都得到了強化，以顯著降低特權濫用的可能性。

另一個重要的防禦是授權控制。Kubernetes支援外掛架構，它允許包含複雜的授權邏輯。正確設計和實施授權;這是反對特權濫用最有效的武器之一。

原文連結：

1、The TopChallenges Kubernetes Users Face with Deployment

https://thenewstack.io/top-challenges-kubernetes-users-face-deployment/

2、4 Threat Models for Kubernetes Deployment Security

https://www.tuicool.com/articles/AfI7RbQ