[[343801]]

 Kubernetes還不到6歲，但它已經(jīng)是每個人最喜歡的容器編排程序了。云和基礎(chǔ)設(shè)施監(jiān)測公司Datadog發(fā)現(xiàn)Kubernetes主導(dǎo)著容器市場：“大約45%的運(yùn)行容器的Datadog客戶使用Kubernetes。”其他容器編排程序，如Marathon和Docker swarm已經(jīng)退出。

Kubernetes在公有云上更受歡迎。例如，根據(jù)Datadog的統(tǒng)計(jì)，“大約80%在Azure中運(yùn)行容器的Datadog客戶現(xiàn)在都在使用Kubernetes”。在亞馬遜網(wǎng)絡(luò)服務(wù)(AWS)上，Datadog發(fā)現(xiàn)它的受歡迎程度在過去兩年翻了一番，達(dá)到了45%。

人氣越高危險(xiǎn)就越大。Windows用戶深知，一個程序越受歡迎，就越容易受到攻擊。Kubernetes也是如此。如果你在使用它，你必須保護(hù)它。

但是這并不容易。

Kubernetes的管理組織Cloud Native Computing Foundation(CNCF)最近對Trail of Bits和Atredis合作伙伴進(jìn)行安全審計(jì)。Bits的報(bào)告說，Kubernetes存在許多安全問題，這是因?yàn)镵ubernetes的配置和部署并不簡單，某些組件的默認(rèn)設(shè)置容易讓人混肴，同時缺少操作控制以及隱式設(shè)計(jì)的安全控制。”

由此可見，這真的不容易。

不過，我們必須嘗試。這是我們?nèi)绾伪ＷCKubernetes安全的前五種方法。

1.確保容器本身安全

如果容器損壞，保護(hù)Kubernetes并沒有任何好處。開源安全公司Snyk在2019年分析了10個最受歡迎的Docker鏡像。他們發(fā)現(xiàn)所有映像都包含易受攻擊的系統(tǒng)庫。

正如VMware副總裁兼首席開源官Dirk Hohndel 在2019年開源領(lǐng)袖峰會上所說的那樣：“容器打包格式類似于Windows中的.exe和macOS中的.dmg，基本上你可以發(fā)布一個包含所有依賴項(xiàng)的完整文件系統(tǒng)。由于您現(xiàn)在將這些依賴項(xiàng)包含在容器中，因此您必須關(guān)注這些二進(jìn)制文件用途，產(chǎn)生方式以及相應(yīng)的來源。“

簡而言之，您必須先確定容器的內(nèi)容是可信任的，然后再將其部署給Kubernetes進(jìn)行管理。否則，您將遇到最常見的計(jì)算機(jī)問題之一：垃圾回收(GIGO)。因此，您別無選擇，只能檢查每個生產(chǎn)容器是否存在潛在的安全問題。

是的，很痛苦。從來沒有人說過安全是容易的。

2.鎖定容器的Linux內(nèi)核

從本處開始只會越來越困難。除了確保容器是安全的以外，由于所有容器都運(yùn)行在單個Linux內(nèi)核上，因此確保該內(nèi)核盡可能安全是有意義的。而且，推薦使用AppArmor或SELinux進(jìn)行安全配置，保護(hù)內(nèi)核。

但是，這些復(fù)雜的配置限制了用戶控制，程序管理，文件訪問和系統(tǒng)維護(hù)。他們將其作為Linux安全模塊來執(zhí)行，該模塊在Linux上強(qiáng)加了強(qiáng)制性訪問控制(MAC)體系結(jié)構(gòu)。對于Linux的內(nèi)置安全模型(除非明確禁止，否則允許一切)，這是一種完全不同的安全方法(除非明確允許，否則限制一切)。

很多系統(tǒng)管理員都無法正確設(shè)置兩者。更糟糕的是，如果您配置錯誤，那這就不僅僅是一個重新配置的過程。如果您配置不對，您的Linux系統(tǒng)將被凍結(jié)，而您將不得不重新進(jìn)行調(diào)整?；蛘?，您可能認(rèn)為它的配置是正確的，但是實(shí)際上您的容器可能仍然會像以前一樣受到攻擊。

正確以及安全的配置需要操作人員的大量時間和專業(yè)知識。在AppArmor或SELinux保護(hù)的內(nèi)核上運(yùn)行應(yīng)用程序可能會遇到困難。大多程序?qū)Φ讓硬僮飨到y(tǒng)采取了安全措施。這些受保護(hù)的內(nèi)核不允許這樣做。

如果這兩種方法中的任何一種被證明是太麻煩了，那么您可以通過阻止內(nèi)核自動加載內(nèi)核模塊來獲得一些保護(hù)。例如，由于即使是非特權(quán)進(jìn)程也可以強(qiáng)制加載一些與網(wǎng)絡(luò)協(xié)議相關(guān)的內(nèi)核模塊，只需創(chuàng)建一個特定的網(wǎng)絡(luò)套接字，就可以添加規(guī)則來阻止有問題的模塊。您可以使用禁止的模塊配置文件來執(zhí)行此操作：

/etc/modprobe.d/kubernetes-blacklist.conf 

文件中記得加入配置說明，例如：

#SCTP在大多數(shù)Kubernetes集群中不使用，并且也有漏洞。

不過，最好的方法還是安裝AppArmor或SELinux。

3.使用基于角色的訪問控制(RBAC)

從Kubernetes1.8開始，您可以使用RBAC來控制用戶可以做什么。這一點(diǎn)很重要，因?yàn)樵噲D將運(yùn)行在數(shù)十個實(shí)例和集群上的用戶混為一談來提供服務(wù)是非常恐怖的。使用RBAC，零信任安全方法，用戶和組件(如應(yīng)用程序和節(jié)點(diǎn))只需要獲得完成任務(wù)所需的權(quán)限。

RBAC在應(yīng)用程序編程接口(API)級別上工作。這樣，即使不使用授權(quán)者本身，RBAC規(guī)則也會鎖定用戶。RBAC還阻止用戶通過編輯角色或角色綁定為自己提供更多特權(quán)。

默認(rèn)情況下，它也會阻止外來者。RBAC策略向控制平面組件、節(jié)點(diǎn)和控制器授予作用域權(quán)限。但是，這一點(diǎn)很重要，它不向kube-system namespace之外的服務(wù)帳戶授予任何權(quán)限。

為了便于管理Kubernetes，RBAC提供了預(yù)定義的角色。這樣，開發(fā)人員、操作員和集群管理員只需獲得他們所需的權(quán)限，而不需要任何用不到的權(quán)限。

在這個系統(tǒng)中，cluster admin角色相當(dāng)于Unix和Linux的超級用戶。群集管理員可以創(chuàng)建、編輯或刪除任何群集資源。不用說，必須小心保護(hù)群集管理員角色的訪問權(quán)限。

4.保守秘密的辛勤工作

Kubernetes Secrets對象包含敏感元素，例如密碼，OAuth令牌或ssh密鑰。簡而言之，它們是Kubernetes集群的鑰匙。您必須保護(hù)好他們。

Kubernetes會自動創(chuàng)建用于訪問API的機(jī)密，并修改您的Pod以使用它們。但是，您的secrets(例如Pod訪問數(shù)據(jù)庫所需的用戶名和密碼)則在您的控制和保護(hù)之下。

很簡單吧?不幸的是，Kubernetes的secrets帶有許多內(nèi)置的安全漏洞。官方所列出的漏洞簡直令人恐懼。

• 在API服務(wù)器，secret數(shù)據(jù)被存儲在ETCD，Kubernetes默認(rèn)使用分布式key-value存儲。默認(rèn)情況下，etcd數(shù)據(jù)不加密，因此您的secrets也不加密。因此，您必須啟用靜態(tài)加密并限制對admin用戶的etcd訪問。
• 許多用戶將其機(jī)密信息保存在JSON或YAML文件中。在這里，機(jī)密數(shù)據(jù)被編碼(未加密)為base64。這意味著如果您共享配置文件或?qū)⑵涮峤坏酱a倉庫中，其他人則可以讀取您的所有secrets。
• 一旦應(yīng)用程序使用了secret，就將不允許該應(yīng)用程序?qū)ζ溥M(jìn)行記錄或?qū)⑵鋫鬏斀o不受信任的一方。
• 一個可以創(chuàng)建使用secret的Pod的用戶也可以看到這個secret的值。即使API服務(wù)器策略不允許該用戶讀取它，用戶也可以運(yùn)行一個Pod，這會暴露secret。
• 當(dāng)前，在任何節(jié)點(diǎn)上具有root權(quán)限的任何人都可以通過模擬kubelet來從API服務(wù)器讀取任何secret。這實(shí)際上是一個特性。其思想是，通過只與需要它們的節(jié)點(diǎn)共享secret，可以將根攻擊對單個節(jié)點(diǎn)造成的損害限制在一個節(jié)點(diǎn)上。

這種情況很糟糕。你可以隨時通過加密secrets來緩解它。如果可能的話，你也應(yīng)該把這個secret與鏡像或pod分開。一種方法是將進(jìn)程拆分為單獨(dú)的容器。例如，可以將應(yīng)用程序分為前端容器和后端容器。后端具有私鑰secret并響應(yīng)來自前端的簽名請求。

除非您既是安全管理員又是Kubernetes管理員，否則必須使用第三方秘密工具來保護(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ò)安全

從上面可以看出，允許訪問etcd非常危險(xiǎn)。正如Kubernetes安全企業(yè)ControlPlane的聯(lián)合創(chuàng)始人Andrew Martin 在Kubernetes自己的博客中寫道：“ 對API服務(wù)器的etcd的寫訪問權(quán)限等同于在整個集群上獲得root權(quán)限，甚至可以很容易的使用讀訪問權(quán)限公平地提升特權(quán)。”

因此，Martin建議：“ etcd應(yīng)該配置有peer和客戶端TLS證書，并部署在專用節(jié)點(diǎn)上。為避免私鑰被從工作節(jié)點(diǎn)竊取和使用，集群也可以通過防火墻連接到API服務(wù)器。

不僅etcd需要網(wǎng)絡(luò)保護(hù)。由于Kubernetes完全由API驅(qū)動，因此默認(rèn)情況下，所有內(nèi)部集群通信均使用TLS加密。

但是，這還不夠。默認(rèn)情況下，Kubernetes Pod接受來自任何來源的流量。在此重復(fù)一遍：“任何來源。” Pod已開放用于網(wǎng)絡(luò)連接，這并不安全。由您決定網(wǎng)絡(luò)策略，該策略可以安全地定義Pod如何在群集內(nèi)以及與外部資源進(jìn)行通信。

您可以通過添加支持網(wǎng)絡(luò)策略控制器的網(wǎng)絡(luò)插件來實(shí)現(xiàn)。如果沒有這樣的控制器，您設(shè)置的任何網(wǎng)絡(luò)策略都不會生效。不幸的是，Kubernetes默認(rèn)沒有官方默認(rèn)甚至首選的網(wǎng)絡(luò)策略控制器。相反，您必須使用第三方插件，如Calico，Cilium，Kube-router，Romana或Weave Net。不管怎樣，我最喜歡的是Calico。

我建議您從**“默認(rèn)拒絕所有**”網(wǎng)絡(luò)策略開始。這樣，僅允許您隨后明確允許的與其他網(wǎng)絡(luò)策略規(guī)則的連接。由于網(wǎng)絡(luò)策略是在namespace中設(shè)置的，因此您需要為每個namespace設(shè)置網(wǎng)絡(luò)策略。

設(shè)置完成后，您可以開始允許適當(dāng)?shù)木W(wǎng)絡(luò)訪問規(guī)則。更多可以參考 【Kubernetes Network Policy Recipes】(https://github.com/ahmetb/kubernetes-network-policy-recipes)。

確保Kubernetes的安全是一項(xiàng)重要工作。

正如我在一開始所說的那樣，保護(hù)Kubernetes確實(shí)不是一件容易的事。到現(xiàn)在為止，我相信您現(xiàn)在是非常同意我這一說法。

Kubernetes從一開始就被設(shè)計(jì)為易于部署。不幸的是，這也意味著它在設(shè)計(jì)上是不安全的。這意味著要增加安全性完全取決于您。幸運(yùn)的是，增加安全性，則使你的Kubernetes集群更具有生產(chǎn)價(jià)值。

本文只談到了Kubernetes安全需要解決的最重要的問題。當(dāng)然還有很多其他的問題。但是，我真的希望我給了你足夠的思路讓你明白這工作有多重要。而且，您必須現(xiàn)在就開始保護(hù)Kubernetes集群，否則黑客會毫不猶豫地提醒您，您已經(jīng)將公司的重要系統(tǒng)暴露在危險(xiǎn)之中。

譯者：祝祥

原文：https://www.idginsiderpro.com/article/3571466/the-five-best-kubernetes-security-practices.html