請保護好這6個被忽視但重要的Kubernetes功能

如果你用過Kubernetes，你就會知道，對于許多人來說，它相當複雜。所有移動部件、網絡以及隻是讓叢集正常啟動和運作，并非易事。這裡所說的“正常”是指安全的，有安全通信、适當的網絡隔離、保護秘密等。

不幸的是，僅僅啟動并運作叢集是不夠的。預設情況下，Kubernetes并不安全。它需要進一步調整，不僅要確定叢集的高安全性，還要確定pod和容器的安全性。

紅帽釋出的《2022年Kubernetes安全報告》對300名DevOps工程師和安全專家進行了民意調查，據報道，受訪者“最擔心容器和Kubernetes環境中的錯誤配置導緻的暴露（46%），幾乎是對攻擊的三倍（16%），而漏洞是第二大擔心原因（28%）。”正确配置重要配置，如基于角色的通路控制（RBAC）和安全上下文，對叢集的安全态勢至關重要。DevOps團隊需要全面考慮許多因素，以及在自己獨特情況的範圍内的事情。

雖然DevOps團隊通常負責叢集的設定和維護，但我們也不能忽視應用程式開發人員所扮演的角色，這些開發人員可能對Kubernetes沒有很好的了解。一旦叢集建立并準備就緒，有時正是開發人員容器化和部署應用程式導緻了pod和容器級别的錯誤配置。

是以，雖然我們無法涵蓋本文中的所有配置，但筆者想介紹一些團隊從叢集部署開始就可以制定的初始政策，這些政策将大大提高安全狀況。通過在叢集設定後實施這六個解決方案，團隊可以大大提高安全性。

1.etcd安全

保護etcd對Kubernetes安全至關重要。所有叢集資料，包括秘密，都儲存在這個高度可用的鍵值存儲中。獲得對etcd的讀寫通路權基本上就是獲得鑰匙。是以，你需要從一開始就為這個重要的後端規劃保護。應該注意的是，Kubernetes-as-a-Service（EKS、AKS等）的一個好處是，此安全措施是托管的。

在保護etcd安全時，需要檢查三件事：

——加密靜态資料。預設情況下，etcd資料不加密。需要建立一個EncryptionConfiguration對象，以便etcd資料在靜止時加密。還支援并建議與第三方密鑰管理服務協作進行此加密的密鑰輪換。

——限制通路。建議分離etcd伺服器并隔離在防火牆後面。從那裡，隻允許從API伺服器通路。不應允許叢集中的其他元件直接通路它。

——確定API伺服器正在使用TLS。

2.網絡政策

如果叢集層在某個點被突破了怎麼辦？我們希望盡可能少的水準滲透，對嗎？預設情況下，Kubernetes允許所有pod-to-pod流量。允許pod之間的所有入站和出站連接配接。如果攻擊者進入一個pod，他們可以不受阻礙地移動到其他pod。

為了防止這種情況發生，應制定網絡政策。在網絡和傳輸層，可以使用Weave Net或Kube-router等網絡插件通過命名空間和标簽限制不必要的pod-to-pod通路。更好的是，可以通過像Istio這樣的服務網格在應用層控制pod流量。

舉一個簡單的例子，如果我們有一個帶有前端、後端和資料庫的應用程式，那麼理想情況下不應該允許前端直接與資料庫對話，也不應該允許資料庫與前端對話。相反，應該隻允許前端與後端對話，然後，後端與資料庫對話。如果攻擊者通路前端應用程式，他們将無法在不經過後端的情況下直接接觸資料庫。

3.pod間通信

除了開放網絡之外，預設情況下，pod-to-pod通信是不加密的。這意味着任何能夠滲透叢集的人都可以用純文字收聽通信。同樣，引入像Istio這樣的服務網格，可以通過将其配置設定為STRICT模式，禁止純文字，進而在服務之間實施互相TLS。這可以局限于命名空間或整個網格，具體取決于用例。

4.秘密

應在早期制定保護秘密的解決方案。然而，通常情況并非如此。事實上，由于建立Kubernetes叢集和運作應用程式的複雜性，秘密管理在許多情況下都被擱置一邊，直到完成更重要的任務。

問題是，Kubernetes雖然為我們提供了一個秘密架構，但在保護它們方面幫不了多少忙。預設情況下，它們僅采用Base64編碼，可以輕松轉換為純文字。當寫入etcd時，此架構可以在靜止狀态下對秘密進行加密；當它與适當的RBAC限制和嚴格的etcd安全性相結合時，它可以變得更安全。然而，這對于生産環境來說仍然不理想。

是以，團隊越早解決秘密管理的問題，安全狀況就會越好。大多數團隊最好使用第三方解決方案，無論是AWS Secrets Manager之類的雲解決方案，還是HashiCorp Vault之類的開源工具。這些将為重要的Kubernetes秘密管理提供一個更加強大和安全的系統。

5.pod級安全/dirty YAML

同樣的盡職調查需要在應用程式級别應用。如前所述，有些應用程式開發人員會在不了解Kubernetes叢集的内部工作原理或理想設定的情況下，将其應用程式打包并部署。公共存儲庫或公共Docker鏡像中的Helm圖表可能包含根級通路或其他可能削弱安全性的潛在關鍵配置。

是以，稽核進入生态系統的YAML配置和容器非常重要。無論是由安全團隊手動執行，還是通過更自動化的方法（如漏洞掃描）執行，這都有助于在潛在漏洞出現之前捕獲它們。

此外，我們應該在pod或容器級别使用Kubernetes安全上下文來阻止任何以root身份運作的鏡像。我們可以将runAsNonRoot為true的securityContext條目添加到YAML中，Kubelet将拒絕啟動預設為root使用者的任何鏡像。當然，退一步來看，應該為鏡像配置設定一個使用者群組UID，但如果沒有，添加此安全上下文将添加另一層防禦。

6.Kubernetes通路

最後，讓我們讨論一下通過API伺服器的通路本身。從技術上講，使用有效證書通路API伺服器的任何使用者都被視為已認證身份驗證。鑒于這一事實，這裡有一些建議：

首先，在大多數情況下，應該通過為API伺服器設定--anonymous auth=false來禁用匿名身份驗證。應設定RBAC以處理特定使用者。然而，如果必須使用匿名身份驗證，RBAC應該大大限制匿名使用者的操作。

其次，預設情況下，API伺服器偵聽兩個端口：一個是安全端口，另一個是不安全的“localhost”端口。你應該通過将--insecure-port标志設定為“0”并確定未設定--insecure bind address來禁用不安全端口。這個不安全的端口實際上會繞過身份驗證和授權檢查，惡意使用者可能會通過它通路主伺服器。

接下來，應建立一個安全且維護良好的RBAC系統，并随時到位。

最後，管理者應該考慮通過OpenID Connect使用公司解決方案（如Active Directory、Okta等）管理普通使用者帳戶。

像Teleport這樣的開源應用程式通過短期的kubeconfig檔案（和證書）單點登入提供對Kubernetes叢集的安全通路。此外，Teleport還提供了其他工具，如内置RBAC系統和kubectl事件的稽核和會話記錄，不僅适用于叢集，還适用于一個圖形使用者界面中的數十、數百、數千個叢集。可以設定角色和政策，讓使用者輕松安全地通路叢集。事實上，使用者從不直接通路叢集，叢集可以隔離在專用網絡或防火牆後面。直接互動僅與Teleport的代理服務進行。

結論

如果你正在啟用一個新叢集，請記住，預設情況下它并不太安全。你需要做一些工作來進一步保護它。從一開始就實施上述六種政策來保護Kubernetes叢集的這些功能，将有助于大大提高叢集的安全性和應用程式的整體成功性。

原文連結：

https://thenewstack.io/6-overlooked-yet-important-kubernetes-features-to-secure/