Kubernetes還不到6歲，但它已經(jīng)是每個(gè)人最喜歡的容器編排程序了。云和基礎(chǔ)設(shè)施監(jiān)測(cè)公司Datadog發(fā)現(xiàn)Kubernetes主導(dǎo)著容器市場(chǎng)：“大約45%的運(yùn)行容器的Datadog客戶(hù)使用Kubernetes。”其他容器編排程序，如Marathon和Docker swarm已經(jīng)退出。
Kubernetes在公有云上更受歡迎。例如，根據(jù)Datadog的統(tǒng)計(jì)，“大約80%在Azure中運(yùn)行容器的Datadog客戶(hù)現(xiàn)在都在使用Kubernetes”。在亞馬遜網(wǎng)絡(luò)服務(wù)(AWS)上，Datadog發(fā)現(xiàn)它的受歡迎程度在過(guò)去兩年翻了一番，達(dá)到了45%。
人氣越高危險(xiǎn)就越大。Windows用戶(hù)深知，一個(gè)程序越受歡迎，就越容易受到攻擊。Kubernetes也是如此。如果你在使用它，你必須保護(hù)它。
但是這并不容易。
Kubernetes的管理組織Cloud Native Computing Foundation(CNCF)最近對(duì)Trail of Bits和Atredis合作伙伴進(jìn)行安全審計(jì)。Bits的報(bào)告說(shuō)，Kubernetes存在許多安全問(wèn)題，這是因?yàn)镵ubernetes的配置和部署并不簡(jiǎn)單，某些組件的默認(rèn)設(shè)置容易讓人混肴，同時(shí)缺少操作控制以及隱式設(shè)計(jì)的安全控制。”
由此可見(jiàn)，這真的不容易。
不過(guò)，我們必須嘗試。這是我們?nèi)绾伪ＷCKubernetes安全的前五種方法。
1.確保容器本身安全
如果容器損壞，保護(hù)Kubernetes并沒(méi)有任何好處。開(kāi)源安全公司Snyk在2019年分析了10個(gè)最受歡迎的Docker鏡像。他們發(fā)現(xiàn)所有映像都包含易受攻擊的系統(tǒng)庫(kù)。
正如VMware副總裁兼首席開(kāi)源官Dirk Hohndel 在2019年開(kāi)源領(lǐng)袖峰會(huì)上所說(shuō)的那樣：“容器打包格式類(lèi)似于Windows中的.exe和macOS中的.dmg，基本上你可以發(fā)布一個(gè)包含所有依賴(lài)項(xiàng)的完整文件系統(tǒng)。由于您現(xiàn)在將這些依賴(lài)項(xiàng)包含在容器中，因此您必須關(guān)注這些二進(jìn)制文件用途，產(chǎn)生方式以及相應(yīng)的來(lái)源。“
簡(jiǎn)而言之，您必須先確定容器的內(nèi)容是可信任的，然后再將其部署給Kubernetes進(jìn)行管理。否則，您將遇到最常見(jiàn)的計(jì)算機(jī)問(wèn)題之一：垃圾回收(GIGO)。因此，您別無(wú)選擇，只能檢查每個(gè)生產(chǎn)容器是否存在潛在的安全問(wèn)題。
是的，很痛苦。從來(lái)沒(méi)有人說(shuō)過(guò)安全是容易的。
2.鎖定容器的Linux內(nèi)核
從本處開(kāi)始只會(huì)越來(lái)越困難。除了確保容器是安全的以外，由于所有容器都運(yùn)行在單個(gè)Linux內(nèi)核上，因此確保該內(nèi)核盡可能安全是有意義的。而且，推薦使用AppArmor或SELinux進(jìn)行安全配置，保護(hù)內(nèi)核。
但是，這些復(fù)雜的配置限制了用戶(hù)控制，程序管理，文件訪問(wèn)和系統(tǒng)維護(hù)。他們將其作為L(zhǎng)inux安全模塊來(lái)執(zhí)行，該模塊在Linux上強(qiáng)加了強(qiáng)制性訪問(wèn)控制(MAC)體系結(jié)構(gòu)。對(duì)于Linux的內(nèi)置安全模型(除非明確禁止，否則允許一切)，這是一種完全不同的安全方法(除非明確允許，否則限制一切)。
很多系統(tǒng)管理員都無(wú)法正確設(shè)置兩者。更糟糕的是，如果您配置錯(cuò)誤，那這就不僅僅是一個(gè)重新配置的過(guò)程。如果您配置不對(duì)，您的Linux系統(tǒng)將被凍結(jié)，而您將不得不重新進(jìn)行調(diào)整。或者，您可能認(rèn)為它的配置是正確的，但是實(shí)際上您的容器可能仍然會(huì)像以前一樣受到攻擊。
正確以及安全的配置需要操作人員的大量時(shí)間和專(zhuān)業(yè)知識(shí)。在AppArmor或SELinux保護(hù)的內(nèi)核上運(yùn)行應(yīng)用程序可能會(huì)遇到困難。大多程序?qū)Φ讓硬僮飨到y(tǒng)采取了安全措施。這些受保護(hù)的內(nèi)核不允許這樣做。
如果這兩種方法中的任何一種被證明是太麻煩了，那么您可以通過(guò)阻止內(nèi)核自動(dòng)加載內(nèi)核模塊來(lái)獲得一些保護(hù)。例如，由于即使是非特權(quán)進(jìn)程也可以強(qiáng)制加載一些與網(wǎng)絡(luò)協(xié)議相關(guān)的內(nèi)核模塊，只需創(chuàng)建一個(gè)特定的網(wǎng)絡(luò)套接字，就可以添加規(guī)則來(lái)阻止有問(wèn)題的模塊。您可以使用禁止的模塊配置文件來(lái)執(zhí)行此操作：
/etc/modprobe.d/kubernetes-blacklist.conf
文件中記得加入配置說(shuō)明，例如：
#SCTP在大多數(shù)Kubernetes集群中不使用，并且也有漏洞。
不過(guò)，最好的方法還是安裝AppArmor或SELinux。
3.使用基于角色的訪問(wèn)控制(RBAC)
從Kubernetes1.8開(kāi)始，您可以使用RBAC來(lái)控制用戶(hù)可以做什么。這一點(diǎn)很重要，因?yàn)樵噲D將運(yùn)行在數(shù)十個(gè)實(shí)例和集群上的用戶(hù)混為一談來(lái)提供服務(wù)是非常恐怖的。使用RBAC，零信任安全方法，用戶(hù)和組件(如應(yīng)用程序和節(jié)點(diǎn))只需要獲得完成任務(wù)所需的權(quán)限。
RBAC在應(yīng)用程序編程接口(API)級(jí)別上工作。這樣，即使不使用授權(quán)者本身，RBAC規(guī)則也會(huì)鎖定用戶(hù)。RBAC還阻止用戶(hù)通過(guò)編輯角色或角色綁定為自己提供更多特權(quán)。
默認(rèn)情況下，它也會(huì)阻止外來(lái)者。RBAC策略向控制平面組件、節(jié)點(diǎn)和控制器授予作用域權(quán)限。但是，這一點(diǎn)很重要，它不向kube-system namespace之外的服務(wù)帳戶(hù)授予任何權(quán)限。
為了便于管理Kubernetes，RBAC提供了預(yù)定義的角色。這樣，開(kāi)發(fā)人員、操作員和集群管理員只需獲得他們所需的權(quán)限，而不需要任何用不到的權(quán)限。
在這個(gè)系統(tǒng)中，cluster admin角色相當(dāng)于Unix和Linux的超級(jí)用戶(hù)。群集管理員可以創(chuàng)建、編輯或刪除任何群集資源。不用說(shuō)，必須小心保護(hù)群集管理員角色的訪問(wèn)權(quán)限。
4.保守秘密的辛勤工作
Kubernetes Secrets對(duì)象包含敏感元素，例如密碼，OAuth令牌或ssh密鑰。簡(jiǎn)而言之，它們是Kubernetes集群的鑰匙。您必須保護(hù)好他們。
Kubernetes會(huì)自動(dòng)創(chuàng)建用于訪問(wèn)API的機(jī)密，并修改您的Pod以使用它們。但是，您的secrets(例如Pod訪問(wèn)數(shù)據(jù)庫(kù)所需的用戶(hù)名和密碼)則在您的控制和保護(hù)之下。
很簡(jiǎn)單吧?不幸的是，Kubernetes的secrets帶有許多內(nèi)置的安全漏洞。官方所列出的漏洞簡(jiǎn)直令人恐懼。
在API服務(wù)器，secret數(shù)據(jù)被存儲(chǔ)在ETCD，Kubernetes默認(rèn)使用分布式key-value存儲(chǔ)。默認(rèn)情況下，etcd數(shù)據(jù)不加密，因此您的secrets也不加密。因此，您必須啟用靜態(tài)加密并限制對(duì)admin用戶(hù)的etcd訪問(wèn)。
許多用戶(hù)將其機(jī)密信息保存在JSON或YAML文件中。在這里，機(jī)密數(shù)據(jù)被編碼(未加密)為base64。這意味著如果您共享配置文件或?qū)⑵涮峤坏酱a倉(cāng)庫(kù)中，其他人則可以讀取您的所有secrets。
一旦應(yīng)用程序使用了secret，就將不允許該應(yīng)用程序?qū)ζ溥M(jìn)行記錄或?qū)⑵鋫鬏斀o不受信任的一方。
一個(gè)可以創(chuàng)建使用secret的Pod的用戶(hù)也可以看到這個(gè)secret的值。即使API服務(wù)器策略不允許該用戶(hù)讀取它，用戶(hù)也可以運(yùn)行一個(gè)Pod，這會(huì)暴露secret。
當(dāng)前，在任何節(jié)點(diǎn)上具有root權(quán)限的任何人都可以通過(guò)模擬kubelet來(lái)從API服務(wù)器讀取任何secret。這實(shí)際上是一個(gè)特性。其思想是，通過(guò)只與需要它們的節(jié)點(diǎn)共享secret，可以將根攻擊對(duì)單個(gè)節(jié)點(diǎn)造成的損害限制在一個(gè)節(jié)點(diǎn)上。
這種情況很糟糕。你可以隨時(shí)通過(guò)加密secrets來(lái)緩解它。如果可能的話，你也應(yīng)該把這個(gè)secret與鏡像或pod分開(kāi)。一種方法是將進(jìn)程拆分為單獨(dú)的容器。例如，可以將應(yīng)用程序分為前端容器和后端容器。后端具有私鑰secret并響應(yīng)來(lái)自前端的簽名請(qǐng)求。
除非您既是安全管理員又是Kubernetes管理員，否則必須使用第三方秘密工具來(lái)保護(hù)您的secret。其中包括AWS Secrets Manager，Google Cloud Platform KMS和用于公共云的Azure Key Vault。而且，程序如Hashicorp Vault, CyberArk/Conjur, Confidant和Aqua Security Kubernetes Security for the Enterprise。
5.保持網(wǎng)絡(luò)安全
從上面可以看出，允許訪問(wèn)etcd非常危險(xiǎn)。正如Kubernetes安全企業(yè)ControlPlane的聯(lián)合創(chuàng)始人Andrew Martin 在Kubernetes自己的博客中寫(xiě)道：“ 對(duì)API服務(wù)器的etcd的寫(xiě)訪問(wèn)權(quán)限等同于在整個(gè)集群上獲得root權(quán)限，甚至可以很容易的使用讀訪問(wèn)權(quán)限公平地提升特權(quán)。”
因此，Martin建議：“ etcd應(yīng)該配置有peer和客戶(hù)端TLS證書(shū)，并部署在專(zhuān)用節(jié)點(diǎn)上。為避免私鑰被從工作節(jié)點(diǎn)竊取和使用，集群也可以通過(guò)防火墻連接到API服務(wù)器。
不僅etcd需要網(wǎng)絡(luò)保護(hù)。由于Kubernetes完全由API驅(qū)動(dòng)，因此默認(rèn)情況下，所有內(nèi)部集群通信均使用TLS加密。
但是，這還不夠。默認(rèn)情況下，Kubernetes Pod接受來(lái)自任何來(lái)源的流量。在此重復(fù)一遍：“任何來(lái)源。” Pod已開(kāi)放用于網(wǎng)絡(luò)連接，這并不安全。由您決定網(wǎng)絡(luò)策略，該策略可以安全地定義Pod如何在群集內(nèi)以及與外部資源進(jìn)行通信。
您可以通過(guò)添加支持網(wǎng)絡(luò)策略控制器的網(wǎng)絡(luò)插件來(lái)實(shí)現(xiàn)。如果沒(méi)有這樣的控制器，您設(shè)置的任何網(wǎng)絡(luò)策略都不會(huì)生效。不幸的是，Kubernetes默認(rèn)沒(méi)有官方默認(rèn)甚至首選的網(wǎng)絡(luò)策略控制器。相反，您必須使用第三方插件，如Calico，Cilium，Kube-router，Romana或Weave Net。不管怎樣，我最喜歡的是Calico。
我建議您從**“默認(rèn)拒絕所有**”網(wǎng)絡(luò)策略開(kāi)始。這樣，僅允許您隨后明確允許的與其他網(wǎng)絡(luò)策略規(guī)則的連接。由于網(wǎng)絡(luò)策略是在namespace中設(shè)置的，因此您需要為每個(gè)namespace設(shè)置網(wǎng)絡(luò)策略。
設(shè)置完成后，您可以開(kāi)始允許適當(dāng)?shù)木W(wǎng)絡(luò)訪問(wèn)規(guī)則。更多可以參考 【Kubernetes Network Policy Recipes】(https://github.com/ahmetb/kubernetes-network-policy-recipes)。
確保Kubernetes的安全是一項(xiàng)重要工作。
正如我在一開(kāi)始所說(shuō)的那樣，保護(hù)Kubernetes確實(shí)不是一件容易的事。到現(xiàn)在為止，我相信您現(xiàn)在是非常同意我這一說(shuō)法。
Kubernetes從一開(kāi)始就被設(shè)計(jì)為易于部署。不幸的是，這也意味著它在設(shè)計(jì)上是不安全的。這意味著要增加安全性完全取決于您。幸運(yùn)的是，增加安全性，則使你的Kubernetes集群更具有生產(chǎn)價(jià)值。
本文只談到了Kubernetes安全需要解決的最重要的問(wèn)題。當(dāng)然還有很多其他的問(wèn)題。但是，我真的希望我給了你足夠的思路讓你明白這工作有多重要。而且，您必須現(xiàn)在就開(kāi)始保護(hù)Kubernetes集群，否則黑客會(huì)毫不猶豫地提醒您，您已經(jīng)將公司的重要系統(tǒng)暴露在危險(xiǎn)之中。
譯者：祝祥
原文：https://www.idginsiderpro.com/article/3571466/the-five-best-kubernetes-security-practices.html
