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資源。