Kubernetes的五種安全實踐

作者： 祝祥 2020-09-25 08:00:57

云計算 Kubernetes還不到6歲，但它已經(jīng)是每個人最喜歡的容器編排程序了。云和基礎設施監(jiān)測公司Datadog發(fā)現(xiàn)Kubernetes主導著容器市場：“大約45%的運行容器的Datadog客戶使用Kubernetes?！逼渌萜骶幣懦绦颍鏜arathon和Docker swarm已經(jīng)退出。

創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供南岔網(wǎng)站建設、南岔做網(wǎng)站、南岔網(wǎng)站設計、南岔網(wǎng)站制作等企業(yè)網(wǎng)站建設、網(wǎng)頁設計與制作、南岔企業(yè)網(wǎng)站模板建站服務，10年南岔做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡服務。

 Kubernetes還不到6歲，但它已經(jīng)是每個人最喜歡的容器編排程序了。云和基礎設施監(jiān)測公司Datadog發(fā)現(xiàn)Kubernetes主導著容器市場：“大約45%的運行容器的Datadog客戶使用Kubernetes?！逼渌萜骶幣懦绦颍鏜arathon和Docker swarm已經(jīng)退出。

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

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

但是這并不容易。

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

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

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

1.確保容器本身安全

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

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

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

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

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

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

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

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

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

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

  
 
 

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

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

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

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

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

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

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

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

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

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

4.保守秘密的辛勤工作

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

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

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

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

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

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

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

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

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

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

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

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

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

確保Kubernetes的安全是一項重要工作。

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

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

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

譯者：祝祥

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

文章名稱：Kubernetes的五種安全實踐
標題URL：http://www.5511xx.com/article/coodopp.html