K8S安全軍規101:對CNCF最佳實踐的擴充
在上篇文章裡,我們分享了CNCF為廣大Kubernetes使用者建議的9項Kubernetes安全最佳實踐,分享了使用者使用Kubernetes管理叢集時的9個能進一步確保叢集安全的基本操作。
上篇文章中的建議非常好,但不足之處在於它們都過於依賴GKE了。對於那些使用谷歌服務的使用者來說,GKE固然是一個很好的解決方案。然而,還有更多的人則是在亞馬遜、Azure、阿里雲、華為雲、DigitalOcean、甚至是他們自己的基礎設施上或其他他們任何想在的地方上執行著Kubernetes叢集,那麼此時,GKE相關的解決方案對他們而言並沒有太大幫助。
對於這些使用者而言,Rancher作為一個開源的解決方案,是一個很棒的選擇。
Rancher Labs對待安全問題十分嚴肅謹慎。Rancher Labs聯合創始人及首席架構師Darren Shepherd,是2018年年底Kuberntes 被爆出的首個嚴重安全漏洞(CVE-2018-1002105)的發現者。安全性不應該是事後的想法,也不應該是部署了不安全的叢集之後才記得要去做的事。就像你建造房子時,不應該把所有物品都搬進去之後,才開始安裝門鎖。
在本文中,我將回顧上篇文章中CNCF提出的每個要點,並向您分析Rancher和RKE能如何在預設設定中滿足這些安全建議。
升級到最新版本
這是一個合理的建議,並且不僅適用於Kubernetes。因為未修補的程式常常是攻擊者的切入點。當某個安全漏洞出現、poc程式碼公開可用時,Metasploit之類的工具套件很快就會在其標準套件中包含這些漏洞。此時,任何會從Internet複製和貼上命令的人都可以控制您的系統。
使用Rancher Kubernetes Engine(RKE)時,無論是單獨使用還是和Rancher一起使用,您都可以選擇要安裝的Kubernetes版本。Rancher Labs使用原生上游Kubernetes,這使公司能夠快速響應安全警報,釋出修復版本的軟體。因為RKE是在Docker容器中執行Kubernetes元件的。運維團隊可以對關鍵基礎架構進行零停機升級。
您可以通過Rancher的GitHub主頁、微信公眾號、官網等各個渠道接收有關新版本釋出的資訊。我還強烈建議您在升級之前,先在staging環境中測試新版本。如果升級出錯,Rancher也可以輕鬆回滾到以前的版本。
啟用基於角色的訪問控制(RBAC)
安裝RKE後,RBAC會預設啟動。如果您只使用RKE或任何其他獨立的Kubernetes部署,則您需要負責配置帳戶、角色和繫結以保護您的叢集。
如果您正在使用Rancher,它不僅會安裝安全叢集,還會通過Rancher伺服器,代理與這些叢集的所有通訊。Rancher可以插入許多後端身份驗證程式,例如Active Directory、LDAP、SAML、Github等。當以這種方式連線時,Rancher使您能夠將現有的企業身份驗證擴充套件到Rancher的保護傘下的所有Kubernetes叢集,無論這些叢集在哪裡執行。
Rancher在全域性、叢集和專案級別啟用角色,使管理員可以在一個位置定義角色並將其應用於所有叢集。這種RBAC-by-default和強大的身份驗證和授權控制的組合意味著從使用Rancher或RKE部署叢集的那一刻起,叢集就是安全的。
使用名稱空間建立安全邊界
由於Kubernetes處理預設名稱空間的特殊方式,我不建議您使用它。我建議您為每個應用程式建立一個名稱空間,將它們定義為邏輯組。
Rancher定義了一個名為Project的附加抽象層。Project是名稱空間的集合,可以在其上對映角色。使用者可能有權訪問某一Project,但他們無法看到任何他們無權訪問的Project中執行的任何工作負載,也無法與其進行互動。這樣一來,其實就是有效地建立了單叢集多租戶。
使用Projects,管理員可以更輕鬆地授予對單個叢集中多個名稱空間的訪問許可權。它最大限度地減少了重複配置以及人為錯誤。
將敏感工作負載彼此分開
這是一個很好的建議,因為它假定了一個問題,“如果工作負載受到損害會發生什麼?”。提前採取行動可以減少破壞地範圍使攻擊者更難以升級許可權,但也並不是完全不可能。所以這可能得花費您額外的時間處理。
Kubernetes允許您設定汙點(taints)和容差(torlerations),從而控制可能部署Pod的位置。
Rancher還允許您通過Kubernetes標籤控制工作負載的排程。除了汙點和容差之外,在部署工作負載時,您可以為主機設定 必須、應該或可以 具有的標籤,這些標籤會控制Pod的部署位置。 如果您的環境是靜態的,您還可以將工作負載安排到特定節點。
安全的雲元資料訪問
該建議指出,敏感的元資料“有時可能被盜或被濫用”,但未能概述“何時”或“如何”的條件。上篇文章中提到了Shopify的賞金細節的洩露, 2018年12月13日的北美KubeCon上提到了這一事件。雖然上篇文章指出GKE具有“元資料隱藏”的功能,但值得注意的是,在最開始洩露憑據的服務,正是Google Cloud元資料API。
此外,沒有任何證據顯示任何其他雲提供商存在相同的漏洞。
此漏洞可能存在的唯一位置是託管的Kubernetes服務,例如GKE。如果您直接或通過Rancher將RKE部署到裸機或雲端計算例項上,您將最終得到一個無法通過雲提供商的元資料API洩露憑據的叢集。
如果您正在使用GKE,我建議您啟用此功能以防止任何憑據通過元資料服務洩漏。我還認為雲提供商不應該將憑證嵌入到可通過API訪問的元資料中。即使這樣做是為了方便,但這是一種不必要的風險,可能會產生難以想象的後果。
建立和定義叢集網路策略
直接部署或由Rancher部署的RKE叢集預設使用Canal,當然,您也可以選擇Calico或Flannel。Canal和Calico都支援網路策略。當使用Canal作為網路提供商時,Rancher部署的叢集也支援Project網路策略。啟用後,工作負載可以與其專案中的其他工作負載通訊,而系統專案(包括入口控制器等叢集範圍的元件)可以與所有專案進行通訊。
早期版本的Rancher預設啟用Project網路策略,但這給一些不瞭解額外安全性的使用者造成了混亂。因此,為了給使用者提供最佳體驗,此功能現在預設情況下已關閉,但如果您想啟用,也可以在啟動後輕鬆啟用。
執行叢集範圍的Pod安全策略
Pod安全策略(PSP)控制Pod必須具有某些功能和配置才能在叢集中執行。例如,您可以阻止特權模式、主機網路或以root身份執行容器。通過Rancher或RKE安裝叢集時,您可以選擇是否要預設啟用受限制的PSP。如果選擇啟用它,則您的叢集將立即對工作負載許可權強制實施強制限制。
受限制的和不受限制的PSP在RKE和Rancher中是相同的,因此它們在安裝時啟用的內容是一樣的。Rancher允許無限數量的額外PSP模板,所有這些都可以在全域性範圍內處理。管理員定義PSP,然後將它們應用於Rancher管理的每個叢集。與前面討論的RBAC配置類似,它將安全配置儲存在一個位置,並大大簡化了策略的配置和應用。
加強節點安全
這不是Kubernetes特定的建議,而是一個很好的普適策略。當要與您無法控制的流量進行互動時(例如,在Kubernetes中執行的應用程式的使用者點選量),應該讓其在攻擊面較小的節點上執行。此外,禁用和解除安裝不需要的服務也是必要的。還有,應該通過SSH限制root訪問許可權並需要sudo密碼加密。在SSH金鑰上使用密碼短語,或使用2FA、U2F金鑰或Krypton等服務將金鑰繫結到使用者擁有的裝置。 以上這些是安全系統的基本標準配置示例。
除了受支援的Docker版本之外,Rancher在主機上不需要其他。並且,RKE只需要SSH訪問,它將在繼續安裝Kubernetes之前安裝Kubernetes支援的最新版本的Docker。
如果您想進一步減少攻擊面,可以瞭解一下RancherOS,這是一個輕量級Linux作業系統,可以將所有程序作為Docker容器執行。System Docker僅執行提供訪問所需的最少數量的程序,並在使用者空間中為實際工作負載執行Docker例項。
啟用稽核日誌(Audit Logging)
Rancher伺服器可在RKE叢集內部執行,因此除了Kubernetes稽核日誌之外,啟用對伺服器本身的API呼叫的稽核日誌也很重要。此日誌將顯示使用者對任何叢集執行的所有操作,包括髮生的事件、執行操作的人員、執行操作的時間以及執行操作的叢集。從有問題的伺服器傳送這些日誌也很重要。Rancher可以連線到Splunk、Elasticsearch、Fluentd、Kafka或任何系統日誌端點,您可以從中生成可疑活動的儀表盤和警報。
有關為Rancher 伺服器啟用稽核日誌的資訊,請參閱我們的文件。
( https://rancher.com/docs/ranc... )
有關為RKE叢集啟用稽核日誌的資訊,請參閱下一節。
安全保障行動正在進行中
真正保護Kubernetes叢集需要9項以上的操作,Rancher有一份安全強化指南( https://rancher.com/docs/ranc... )和一份自我評估指南( https://releases.rancher.com/... ),涵蓋了CIS基準用於保護Kubernetes的100多種控制。
如果您十分在意安全性,那麼Rancher、RKE以及RancherOS將會幫助您。