12 個 Kubernetes 最佳安全加固指南

語言: CN / TW / HK

在容器環境中,K8S管理著擁有數個、數百個甚至數千個節點的容器叢集,其配置的重要性不可忽略。K8S的配置選項很複雜,一些安全功能並非預設開啟,這加大了安全管理難度。如何有效地使用包括Pod安全策略、網路策略、API伺服器、Kubelet及其他K8S元件和功能策略建立安全的K8S環境?青藤雲安全為你整理了以下12個最佳實踐,對K8S進行全面加固。

1.將K8S更新到最新穩定版本

K8S新版本通常會引入一系列不同的安全功能,提供關鍵的安全補丁等,將K8S部署更新到最新穩定版本,使用到達stable狀態的API,能夠補救一些已知的安全風險,幫助解決影響較大的K8S安全缺陷問題,大大減少攻擊面。

2.利用Pod策略防止風險容器/Pod被使用

PodSecurityPolicy是K8S中可用的叢集級資源,通過啟用PodSecurityPolicy准入控制器來使用此功能。使用者至少要授權一個策略,否則將不允許在叢集中建立Pod。Pod安全策略解決了以下幾個關鍵安全用例:

●   防止容器以特權模式執行,因為這種型別的容器將會擁有底層主機可用的大部分能力。

●  避免容器與宿主機共享非必要的名稱空間,如PID、IPC、NET等,確保Docker容器和底層主機之間的適當隔離。

●  限制Volume的型別。例如,通過可寫HostPath目錄卷,操作者可寫入檔案系統,讓容器得以在pathprefix之外隨意移動,因此,必須使用readonly:true。

●   限制主機檔案系統的使用。

●   通過

ReadOnlyRootFilesystem將根檔案系統設定為只讀。

●  基於

defaultAllowPrivilegeEscalation和

allowPrivilegeEscalation選項,防止Pod及Pod中的程序獲得高許可權。

●  在遵循最小許可權原則的前提下,將Linux功能限制為最低許可權。

此外,一些Pod屬性也可以通過SecurityContext來控制。

3.利用K8S名稱空間正確隔離K8S資源

通過名稱空間可以建立邏輯分割槽、強制分離資源以及限制使用者許可權範圍。在一個名稱空間內的資源名稱必須是唯一的,且不能相互巢狀,每個K8S資源只能位於一個名稱空間中。在建立名稱空間時,要避免使用字首kube-,因為kube-用於K8S系統的名稱空間。

4.利用網路策略限制容器和Pod通訊

網路策略功能規定了Pod群組之間相互通訊以及Pod群組與其他網路端點間進行通訊的方式,可以理解為K8S的防火牆。雖然Kubernetes支援對NetworkPolicy資源的操作,但如果沒有實現該資源的外掛,僅建立該資源是沒有效果的,可以通過使用支援網路策略的網路外掛,比如Calico、Cilium、Kube-router、Romana和Weave Net等。

如果有一個適用於Pod的網路策略被允許,那麼與Pod的連線就會被允許。要明確可以允許哪些Pod訪問網際網路,如果在每個名稱空間內使用了default-deny-all命令,那所有的Pod都不能相互連線或接收來自網際網路的流量。對於大多數應用程式來說,可以通過設定指定標籤的方式,建立針對這些標籤的網路策略來允許一些Pod接收來自外部的流量。

5.利用ImagePolicyWebhook策略管理映象來源

可以通過准入控制器ImagePolicyWebhook來防止使用未經驗證的映象,從而拒絕使用未經驗證的映象來建立Pod,這些映象包括近期未掃描過的映象、未列入白名單的基礎映象、來自不安全的映象倉庫的映象。

6.安全配置K8S API伺服器

Kubernetes API 伺服器處理來自叢集內執行的使用者或應用程式的 REST API 呼叫,以啟用叢集管理。在主節點執行ps -ef | grep kube-apiserver命令,並檢查輸出中的以下資訊:

7.安全配置Kube-scheduler

Kube-scheduler作為K8S的預設編排器,負責監視未分配節點的新建立的Pod,從而將該Pod排程到合適的Node上執行。在主節點上執行ps -ef | grep kube-scheduler命令,並檢查輸出中的以下資訊:

●  -- profiling設定為false,以大大減少攻擊面。當遇到系統性能瓶頸的時候,profiling可以通過識別定位瓶頸來發揮作用,對效能調優有顯著幫助。

●  - - address設定為127.0.0.1,防止將編排器繫結到一個非迴環的不安全地址。

8.安全配置Kube-controller-manager

在主節點上執行ps-ef | grep kube-controller-manager命令,並檢查輸出中的以下資訊:

●  - - terminated-pod-gc-threshold設定為一個適合的值,以確保擁有足夠可用的資源,並不會導致效能降低。

●  - - profilingargument 設定為false。

●  - - use-service-account-credentials設定為true。這種設定可以配合RBAC使用,確保控制環路以最小許可權原則執行。

●  -- service-account-private-key-file設定為單獨的公鑰/私鑰對,用於簽署服務賬戶令牌。

●  -- root-ca-file設定為一個適合的值,在包含API伺服器的服務證書的根證書中進行設定,這樣Pod會先驗證API伺服器的服務證書,然後再建立連線。

-- RotateKubeletServerCertificate設定為true,並且只適用於Kubelets從API伺服器獲得其證書的情況下。

●  -- address argument設定為

127.0.0.1,確保控制管理器服務不會與非迴環的不安全地址繫結。

9.安全配置Etcd

Etcd是一種分散式鍵值儲存,實現跨叢集儲存資料。K8S叢集都使用Etcd作為主要的資料儲存方式,來處理K8S叢集狀態的儲存和複製資料,使系統人員可以根據需要從Etcd讀取並寫入資料。安全地配置Etcd與其伺服器的通訊是最關鍵的。在Etcd伺服器節點上執行ps -ef | grep etcd命令,並檢查輸出中的以下資訊

●  --cert-file和 --key-file根據需要設定,以確保客戶端連線只通過TLS(傳輸中加密)提供服務。

●  --client-cert-auth 設定為true,確保所有使用者的訪問都會包括一個有效的客戶端證書。

●  --auto-tls不要設定為true,這會禁止客戶在TLS中使用自簽名的證書。

●  如果使用的是Etcd叢集(而非單一的Etcd伺服器),要檢查一下--peer-cert-file 和--peer-key-file 引數是否設定正確,以確保同級別的Etcd連線在Etcd叢集中被加密。此外,檢查--peer-client-cert-auth 引數是否設定為true,確保只有經過認證的同級別的Etcd才能訪問Etcd叢集。最後檢查一下--peer-auto-tls 引數是否設定為true。

●  不要為Etcd與Kubernetes使用相同的授權證書,可以通過驗證API伺服器的--client-ca-file引用的檔案與Etcd使用的--trusted-ca-file之間的差別來確保這種區分情況。

10.安全配置Kubelet

Kubelet是執行在每個節點上的主要“節點代理”,錯誤地配置Kubelet會面臨一系列的安全風險,所以,可以使用執行中的Kubelet可執行檔案引數或Kubelet配置檔案來設定Kubelet配置。找到Kubelet配置檔案(通過config 引數可找到Kubelet配置檔案的位置),執行ps -ef | grep kubelet | grep config 命令,並檢查輸出中的以下資訊:

●  --anonymous-auth 設定為false。常見的錯誤配置之一是允許Kubelet伺服器提供匿名和未經驗證的請求。

●  --authorization-mod設定為

AlwaysAllow。 若使用預設配置值,要確保有--config 指定的Kubelet配置檔案,並且該檔案將authorization: mode 設定為AlwaysAllow以外的配置。

●  --client-ca-file 設定的是客戶端證書授權的位置。若使用預設配置值,要確保有一個由--config指定的Kubelet配置檔案,並且該檔案已經過認證,同時將x509:clientCAFile 設定為客戶端證書授權的位置。

●  --read-only-port 設定為0,若使用預設配置值,要確保有一個由config指定的檔案,如果要設定適合的值,則將readOnlyPort設定為0。

●  --protect-kernel-defaults

設定為true。若使用預設配置值,要確保有一個由config指定的檔案,並且該檔案已將protectKernelDefaults設定為true。

●  --hostname-override 

使用預設配置值,確保Kubelet和API伺服器之間TLS設定沒有中斷。

●  --event-qps設定為0。若使用預設配置值,要確保有一個由config指定的kubelet配置檔案,並且eventRecordQPS設定為0。

●  --tls-cert-file和--tls-private-key-file引數設定為合適的值。通過--config所指定的Kubeletconfig包含tlsCertFile和tlsPrivateKeyFile,確保Kubelet上的所有連線都是通過TLS進行的。

●  如果Kubelet從API伺服器獲得證書,將

RotateKubeletServerCertificate和--rotate-certificates設定為true,確保Kubelet只使用強密碼。

11.確保主節點的配置檔案安全

主節點上的配置檔案安全主要涉及到確保API伺服器的Pod規範檔案許可權和所有權、控制管理器Pod規範檔案的許可權和所有權、編排器Pod規範檔案的許可權和所有權、Etcd Pod規範檔案的許可權和所有權、容器網路介面檔案的許可權和所有權、Etcd資料目錄的許可權和所有權、admins.conf檔案的許可權和所有權、scheduler.conf檔案的許可權和所有權、controller-manager.conf檔案許可權和所有權、Kubernetes PKI目錄&檔案許可權和所有權、Kubernetes PKI金鑰檔案許可權等安全性。

以API伺服器的Pod規範檔案許可權和所有權為例:

檔案許可權:在主節點上執行stat-c%a /etc/kubernetes/manifests/kube-apiserver.yaml 命令 (指定系統的檔案位置),在輸出中檢查和確保許可權是644或更多許可權限制,並保持檔案的完整性。

所有權:在主節點上執行stat-c%U:%G /etc/kubernetes/manifests/kube-apiserver.yaml命令 (指定系統的檔案位置),在輸出中檢查和確保所有權許可權設定為root:root。

12.確保工作節點的配置檔案安全

保護工作節點的配置檔案安全包括確保Kubelet服務檔案許可權、Kubelet.conf檔案許可權和所有權、Kubelet服務檔案所有權、代理Kubeconfig檔案的許可權和所有權、證書管理中心的檔案許可權、客戶端證書管理中心的檔案所有權、Kubelet配置檔案的許可權和所有權。

以Kubelet服務檔案許可權為例:在主節點上執行 stat-c%a /etc/systemd/system/kubelet.service.d/10-kubeadm.conf命令 (指定系統的檔案位置),在輸出中檢查和確保許可權是644或更多許可權限制,並保持檔案的完整性。

總結

K8S提供了建立安全應用的強大功能,但我們需要確保所有的配置設定正確。上文介紹的這些配置、程式碼示例和詳細建議,可幫助您避免最常見的K8S錯誤配置相關的安全風險。

本文轉載自:「青藤雲安全」,原文:https://tinyurl.com/rnhar5k3,版權歸原作者所有。

推薦閱讀 點選標題可跳轉

《Docker是什麼?》

《Kubernetes是什麼?》

《Kubernetes和Docker到底有啥關係?》

《教你如何快捷的查詢選擇網路倉庫映象tag》

《Docker映象進階:瞭解其背後的技術原理》

《教你如何修改執行中的容器埠對映》

《k8s學習筆記:介紹&上手》

《k8s學習筆記:縮擴容&更新》

《Docker 基礎用法和命令幫助》

《在K8S上搭建Redis叢集》

《灰度部署、滾動部署、藍綠部署》

《PM2實踐指南》

《Docker垃圾清理》

《Kubernetes(k8s)底層網路原理刨析》

《容器環境下Node.js的記憶體管理》

《MySQL 快速建立千萬級測試資料》

《Linux 與 Unix 到底有什麼不同?》

《淺談幾種常見 RAID 的異同》

《Git 筆記-程式設計師都要掌握的 Git》

《老司機必須懂的MySQL規範》

《Docker中Image、Container與Volume的遷移》

《漫畫|如何用Kubernetes搞定CICD》

《寫給前端的Docker實戰教程》

《Linux 作業系統知識地圖2.0,我看行》

《16個概念帶你入門 Kubernetes》

《程式設計師因接外包坐牢456天,長文敘述心酸真實經歷》

《IT 行業老鳥,有話對你說》

《HTTPS 為什麼是安全的? 說一下他的底層實現原理?

免責宣告:本文內容來源於網路,所載內容僅供參考。轉載僅為學習和交流之目的,如無意中侵犯您的合法權益,請及時聯絡Docker中文社群!