Kubernetes安全三步談：三種方法保護Kubernetes免受內部威脅

這是關于Kubernetes安全系列三篇文章中的第二篇。在上篇文章中我們分享了如何確保企業的Kubernetes集群免受外部***，這篇文章中我們將分享三種保護Kubernetes免受內部威脅的方法，后續我們還想介紹如何處理資源消耗或noisy neighbor問題。

本質上講，Kubernetes集群是多用戶的。因此，組織通常希望通過RBAC（基于角色的訪問控制）、邏輯隔離和網絡策略來確保交叉通信受到保護。

像Kubernetes這樣的容器編排系統將開發人員和運維人員（DevOps）更緊密地聯系在一起，使團隊更容易有效地相互協作。誠然，我們相信DevOps團隊的大多數成員不會存在什么惡意企圖，但是，組織仍然需要確保，如果應用程序之間存在交叉通信，并且如果有人編寫了錯誤代碼，我們能夠將損失控制在最小。

01 基于角色的訪問控制

減輕對容器的惡意威脅與保護物理服務器，這兩者的策略不同。然而，無論系統管理員是在數據中心部署了多個服務器，還是在Kubernetes中部署了虛擬集群，基于角色的訪問控制（RBAC）都是一項至關重要的安全舉措。

Rancher Labs的高級解決方案架構師Adrian Goins說，“在內部，你希望有某種基于角色的訪問控制，遵循最低特權的規則。”Rancher Labs為Kubernetes開發了一個完整的容器管理平臺Rancher。

“你只允許用戶和服務賬戶訪問他們需要訪問的資源，而且訪問權限只適用于他們需要做的任何事情。”這種訪問控制向下擴展到無需使用root權限來運行容器進程。

Rancher與RBAC的多個后端提供者交互，簡化了Kubernetes用戶的流程。例如，系統管理員可以部署Rancher并去到authentication選項卡，將其組織的Microsoft Active Directory數據導入到Kubernetes中。Rancher會立即從Activate Directory中提取所有用戶和組，這些組現在可以在角色中使用，然后應用于Rancher管理的所有集群。

通常情況下，管理員必須手動配置這些角色，并在每個集群中復制它們。對于一個擁有一到兩個集群的組織來說，這可能不是什么問題，但是如果一個公司擁有數十個、數百個或更多集群，那么人為錯誤的可能性非常高。總有一些東西會遺漏，其后果可能是災難性的。

通過Rancher，管理員可以跨集群將角色集中化，drill down以讓用戶訪問只能執行特定任務的特定集群。如果有員工離職了，只需要停用Active Directory中他們的賬戶就行，一切都非常簡單。完成此操作后，被停用的賬戶會立刻失去訪問每個集群的權限。因為Rancher充當了每個集群的身份驗證代理，管理員不再需要為部署集群所在的每個提供者提供或管理賬戶。

02 使用命名空間進行邏輯隔離

此外，部署到集群的應用應該使用命名空間，將資源進行邏輯隔離后，管理員可以給它們附加安全策略。命名空間可以給集群資源分段，并且包括它們所包含的pod的配額以及默認資源限制。盡管命名空間最初的目的是用于跨多個團隊或項目的多用戶環境，但現在它已經是公認的集群內的最佳標準實踐了。

默認情況下，在Kubernetes中，沒有任何東西可以阻止擁有容器的兩個不同團隊進行對話。但是，Kubernetes的RBAC功能就能限制這種通信。

“我們可以說，我的命名空間中的容器只能夠與同一命名空間內的容器通信，而不允許與其他命名空間中的容器通信。”Goins說，此外，“可以這么說，作為用戶，我只允許與我自己的命名空間對話，而你作為用戶，你也只允許和自己的命名空間對話。這是工作負載層面以及用戶層面的安全性。如果操作正確，用戶甚至無法看到另一個工作負載的存在。”

這是Kubernetes的功能之一——單個集群中的多租戶。但是，Rancher對命名空間功能進行了進一步拓展，整合了“項目”資源，以幫助減輕集群的管理負擔。

在Rancher中，項目（Projects）允許管理員在單個實體下收集多個命名空間。在Kubernetes的基礎版本中，RBAC或集群資源等特性被分配給各個命名空間。在有些Kubernetes集群里，多個命名空間需要相同的訪問權限，而手動將這些權限分配給每個命名空間，可以說是一項乏味的任務。即使所有命名空間都需要相同的權限，也無法保證在一個操作中能將這些權限應用于所有命名空間。Goins指出，管理員必須重復地將這些權限分配給每個命名空間。

而Rancher的Project概念，讓管理員可以在項目層級分配資源和訪問權限，從而解決了上述問題。然后項目中的每個命名空間繼承這些資源和策略，因此管理員只需將它們分配給項目一次，而不是將它們分配給每個命名空間。

通過Project，管理員可以執行很多操作，例如為用戶分配訪問一組命名空間的權限、為用戶分配項目中的特定角色、為項目分配資源、分配pod安全策略等等。

03 NetworkPolicy資源

NetworkPolicy是一種Kubernetes資源，用于配置pod（具有共享存儲和網絡資源的一個或多個容器的邏輯組）如何相互通信或如何與其他網絡端點通信。

默認情況下，pods是非隔離的，這意味著它們會接受來自任何來源的流量。Goins解釋說：“NetworkPolicy就像Kubernetes集群上運行的pods之間基于軟件的防火墻。管理員可以為命名空間創建‘默認’隔離策略，方法是先創建一個NetworkPolicy，選擇所有pods，但不允許向這些pods發送任何傳入或傳出的流量。”

此外，管理員可以配置哪些pods可以彼此連接。這些策略可以再進一步詳細描述，讓管理員可以指定哪些命名空間可以通信，或者選擇端口號來執行每個策略。

NetworkPolicy資源需要支持配置的網絡后端，如Calico、Canal、Romana或Weave。根據Kubernetes文檔，簡單地創建資源而沒有控制器來實現它是沒有效果的。

04 防范內部威脅

盡管有一些默認工具可以保護Kubernetes安全，但其中許多工具似乎只是為了防止外部威脅到集群。更有甚者，它們甚至很難進行擴展。若企業想要保護集群不受內部威脅（無論是來自實際的惡意內部威脅，還是僅僅是防止錯誤或錯誤編碼傳播）時，防御的手段非常少。

不過所幸的是，有一些解決方案已經著眼于保護集群免受未經授權的內部訪問。其中一些存在于Kubernetes框架中，比如命名空間，而Rancher的Project則在默認設置之上還有進一步擴展，以便對整個企業環境進行更精確的管理和控制。

關鍵的是，不要在內部資源的網絡安全問題上感到放棄或者氣餒。遵循本文的三個步驟，您依然可以在嚴格控制內部訪問保護的同時獲得使用Kubernetes集群最高效率。

下篇文章將是本系列文章的最后一篇，我們將來看看如何處理資源限制的問題，如何防止用戶過度消耗Kubernetes資源。