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