如何應對Kubernetes的安全挑戰？

根據CNCF對各種規模的公司中1340位技術專家的最新調查，有78％的受訪者在生產中使用開源容器編排工具。這比去年的58％有所增加。

但是，儘管Kubernetes是GitHub上最受歡迎的專案之一，但許多組織仍對其複雜性感到震驚。

更多開源資訊及乾貨內容歡迎關注微信公眾號“開源村OSV”

組織已經看到了構建微服務的價值-將應用程式作為離散的功能部分交付，每個部分都可以作為容器交付並單獨管理。但是對於每個應用程式，都有更多的部分需要管理，尤其是在規模方面。

Kubernetes透過提供一個可擴充套件的宣告性平臺來解決該問題，該平臺可自動化容器管理以實現高可用性，彈性和規模。但是，Kubernetes是一個龐大，複雜，快速發展，有時令人困惑的平臺，需要使用者開發新技能。Kubernetes專案本身最近完成了安全稽核。

制定雲原生策略（包括應使用哪些平臺和工具來確保雲原生應用安全部署）的公司可能會從瞭解Kubernetes的安全挑戰中受益，這主要歸結為四個方面。

以下是您將面臨的挑戰，以及緩解這些挑戰的建議。

1.強化和合規

使用Kubernetes時，您必須將注意力集中在預設情況下處於開啟狀態和未開啟狀態的內容上。例如，pod安全策略是保護多租戶群集的關鍵，但該功能仍為beta，預設情況下未啟用。功能豐富的Kubernetes平臺可能使理解預設功能具有挑戰性，但是弄清楚預設功能是必不可少的。

組織可以使用安全性基準來加強Kubernetes。例如，Internet安全中心提供了配置指南，以加強系統（包括Kubernetes）以抵抗不斷髮展的網路威脅。

擁有這種型別的分步清單可以大大確保保護像Kubernetes這樣複雜的系統。但是，由於安全性始終與風險管理有關，因此組織需要評估某些設定對效能的影響，並權衡風險與收益。

一些組織沒有技能或時間獨自加強Kubernetes。確保設定和維護叢集所需的配置以包括諸如確保始終透過HTTPS始終訪問API伺服器，使用X.509證書來認證平臺元件之間的通訊之類的工作，可能是一項艱鉅的工作。etcd資料儲存已加密。

甚至這個相對較短的清單也不堪重負的組織可能希望考慮已經進行了強化的Kubernetes的商業實現。

2.管理叢集上部署的所有工作負載的配置

除了管理群集的配置之外，組織還需要管理群集上執行的所有工作負載的配置。您可以使用開源工具頭盔圖表來自動執行應用程式供應和配置，以及部署簡單或幾個獨立的服務由複雜的應用程式Kubernetes。

但是，雖然Helm對於管理第1天的操作非常有用，但它並沒有擴充套件到第2天的操作，這正是Kubernetes運營商的亮點。

運營商是打包，部署和管理旨在在Kubernetes上執行的複雜應用程式的一種方式。運營商獲取人類操作知識，並將其編碼為與應用程式打包在一起並共享的軟體。

它們使應用程式開發人員更容易為在Kubernetes上執行的服務提供自動化的生命週期管理。Helm Charts也可以包裝在Kubernetes運算子中並一起使用。

在安全性方面，運營商確保在Kubernetes上部署的服務保持受支援的配置。如果對已部署的服務進行了不受支援的配置，則操作員可以將服務重置為其原始的宣告配置。

真正有趣的是，您可以使用Kubernetes運營商來管理Kubernetes本身，從而使交付和自動化安全部署變得更加容易。

更多開源資訊及乾貨內容歡迎關注微信公眾號“開源村OSV”

3.管理多租戶叢集

隨著Kubernetes的擴充套件，管理部署在叢集上以及叢集本身上的所有工作負載變得越來越困難。多租戶是處理可能容易變得混亂的最有效方法之一。實際上，Kubernetes對多租戶的支援已經走了很長一段路。

關鍵功能包括以下功能（您應注意，預設情況下並不總是將其開啟）：

名稱空間，當與RBAC（定義如下）和網路策略一起使用時，允許組織隔離同一物理群集中的多個團隊。

基於角色的訪問控制（RBAC）確定是否允許使用者在叢集或名稱空間內執行給定的操作。為了幫助簡化RBAC的使用，請考慮使用預設角色，這些角色可以繫結到整個群集範圍內或每個名稱空間本地的使用者和組。

Kubernetes中的資源配額限制了每個名稱空間的總資源消耗，使系統更不容易受到諸如拒絕服務之類的攻擊。預設情況下，Kubernetes叢集中的所有資源都是使用無限制的CPU和記憶體請求/限制建立的。

微分段的網路策略指定Pod組之間如何相互通訊以及與其他網路端點通訊。策略是基於名稱空間的。預設情況下，如果在名稱空間中未設定任何策略，則允許傳入和傳出該名稱空間中的Pod的流量。

4.平衡安全性和敏捷性

組織不斷創新的壓力越來越大，這使得將安全性作為事後考慮變得容易。理想情況下，安全性是內建在DevOps週期中的，但是組織可以透過在DevOps中間顯式新增“ sec”，或者透過在流水線中構建儘可能多的安全自動化來受益。

為確保應用開發組織可以實施最佳安全實踐，請後退一步，然後重新訪問CI / CD管道。他們是否使用自動化的單元測試和功能測試？他們是否整合了自動安全門，例如整合的漏洞掃描器？

透過在開發和生產叢集中新增功能，Ops可以為DevSecOps提供幫助，使應用程式開發團隊可以輕鬆地以統一的方式利用監視，警報和日誌記錄服務，同時開發和部署基於微服務的應用程式。

此外，雖然向Kubernetes叢集新增服務網格似乎增加了複雜性，但實際上使重要的業務邏輯更加可見。以前，開發人員需要在其程式碼中構建邏輯。現在，這些功能可以作為Kubernetes平臺的一部分使用，從而節省了開發人員的工作量並加快了微服務的交付。

服務網格還為操作團隊提供了微服務互動的更多可見性，尤其是當可觀察性和東西向群集流量的視覺化作為服務網格解決方案的一部分時。

但這不僅僅是工具。這也與文化和過程有關。理想情況下，這種自我評估工作以及對CI / CD管道的更改是與組織的安全團隊協作完成的，從而為開發人員提供了一個學習更多有關安全性的機會，反之亦然。畢竟，安全專業人員短缺，所以讓我們共同努力，分散財富。

在您的軟體中構建安全功能，可以使您的組織儘可能輕鬆地實現其安全目標，而不必依賴大量可能協同工作或協同工作的點產品。

看到Kubernetes社群不僅投資於傳統的安全評估（例如Kubernetes安全稽核），而且還投資於增強安全性的全部功能，這真是太棒了，這些功能包括強化指南，RBAC，pod安全策略，網路策略，服務網格，和運營商。

更多開源資訊及乾貨內容歡迎關注微信公眾號“開源村OSV”