Kubernetes安全三步談：三種方法保護(hù)Kubernetes免受內(nèi)部威脅

ghnor 發(fā)布于2019-07-01 17:09 / 1831人閱讀

摘要：若企業(yè)想要保護(hù)集群不受內(nèi)部威脅無論是來自實(shí)際的惡意內(nèi)部威脅，還是僅僅是防止錯(cuò)誤或錯(cuò)誤編碼傳播時(shí)，防御的手段非常少。不過所幸的是，有一些解決方案已經(jīng)著眼于保護(hù)集群免受未經(jīng)授權(quán)的內(nèi)部訪問。

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

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

像Kubernetes這樣的容器編排系統(tǒng)將開發(fā)人員和運(yùn)維人員（DevOps）更緊密地聯(lián)系在一起，使團(tuán)隊(duì)更容易有效地相互協(xié)作。誠然，我們相信DevOps團(tuán)隊(duì)的大多數(shù)成員不會存在什么惡意企圖，但是，組織仍然需要確保，如果應(yīng)用程序之間存在交叉通信，并且如果有人編寫了錯(cuò)誤代碼，我們能夠?qū)p失控制在最小。

01 基于角色的訪問控制

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

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

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

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

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

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

02 使用命名空間進(jìn)行邏輯隔離

此外，部署到集群的應(yīng)用應(yīng)該使用命名空間，將資源進(jìn)行邏輯隔離后，管理員可以給它們附加安全策略。命名空間可以給集群資源分段，并且包括它們所包含的pod的配額以及默認(rèn)資源限制。盡管命名空間最初的目的是用于跨多個(gè)團(tuán)隊(duì)或項(xiàng)目的多用戶環(huán)境，但現(xiàn)在它已經(jīng)是公認(rèn)的集群內(nèi)的最佳標(biāo)準(zhǔn)實(shí)踐了。

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

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

這是Kubernetes的功能之一——單個(gè)集群中的多租戶。但是，Rancher對命名空間功能進(jìn)行了進(jìn)一步拓展，整合了“項(xiàng)目”資源，以幫助減輕集群的管理負(fù)擔(dān)。

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

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

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

03 NetworkPolicy資源

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

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

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

NetworkPolicy資源需要支持配置的網(wǎng)絡(luò)后端，如Calico、Canal、Romana或Weave。根據(jù)Kubernetes文檔，簡單地創(chuàng)建資源而沒有控制器來實(shí)現(xiàn)它是沒有效果的。

04 防范內(nèi)部威脅

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

不過所幸的是，有一些解決方案已經(jīng)著眼于保護(hù)集群免受未經(jīng)授權(quán)的內(nèi)部訪問。其中一些存在于Kubernetes框架中，比如命名空間，而Rancher的Project則在默認(rèn)設(shè)置之上還有進(jìn)一步擴(kuò)展，以便對整個(gè)企業(yè)環(huán)境進(jìn)行更精確的管理和控制。

關(guān)鍵的是，不要在內(nèi)部資源的網(wǎng)絡(luò)安全問題上感到放棄或者氣餒。遵循本文的三個(gè)步驟，您依然可以在嚴(yán)格控制內(nèi)部訪問保護(hù)的同時(shí)獲得使用Kubernetes集群最高效率。

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