[[343801]]

 Kubernetes還不到6歲，但它已經是每個人最喜歡的容器編排程序了。云和基礎設施監測公司Datadog發現Kubernetes主導著容器市場：“大約45%的運行容器的Datadog客戶使用Kubernetes。”其他容器編排程序，如Marathon和Docker swarm已經退出。

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

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

但是這并不容易。

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

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

不過，我們必須嘗試。這是我們如何保證Kubernetes安全的前五種方法。

1.確保容器本身安全

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

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

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

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

2.鎖定容器的Linux內核

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

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

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

正確以及安全的配置需要操作人員的大量時間和專業知識。在AppArmor或SELinux保護的內核上運行應用程序可能會遇到困難。大多程序對底層操作系統采取了安全措施。這些受保護的內核不允許這樣做。

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

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

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

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

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

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

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

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

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

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

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

4.保守秘密的辛勤工作

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

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

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

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

這種情況很糟糕。你可以隨時通過加密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.保持網絡安全

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

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

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

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

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

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

設置完成后，您可以開始允許適當的網絡訪問規則。更多可以參考 【Kubernetes Network Policy Recipes】(https://github.com/ahmetb/kubernetes-network-policy-recipes)。

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

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

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

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

譯者：祝祥

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