12 個 Kubernetes 最佳安全加固指南
在容器環境中,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錯誤配置相關的安全風險。
本文轉載自:「青藤雲安全」,原文:http://tinyurl.com/rnhar5k3,版權歸原作者所有。
推薦閲讀 點擊標題可跳轉
《Docker中Image、Container與Volume的遷移》
《HTTPS 為什麼是安全的? 説一下他的底層實現原理? 》
免責聲明:本文內容來源於網絡,所載內容僅供參考。轉載僅為學習和交流之目的,如無意中侵犯您的合法權益,請及時聯繫Docker中文社區!
- 6 款適用於 Linux 的最佳免費殺毒軟件
- 17 張程序員壁紙(使用頻率很高)
- 【Docker】【GitLab】dokcer 安裝搭建最新 gitlab 中文社區版 (搭建一個小型個人的“Gitee” 或 “GitHub”)
- 解決 Jenkins 性能緩慢的問題
- Kubernetes RBAC (基於角色的訪問控制) 的演進歷史、設計理念及簡潔實現
- 殼牌公司是如何在Kubernetes上不到一天就建立了1萬個AI模型的?
- 運行 Kubernetes 集羣故障分析案例!
- 如何給 Docker 鏡像進行安全簽名
- 入口控制器:Kubernetes的瑞士軍刀
- 12 個 Kubernetes 最佳安全加固指南
- 4種 Kubernetes 命名空間永遠不要觸碰!
- 一次內核問題引起的 Kubernetes 節點故障解決記實
- Colima:Docker Desktop for Mac 的免費替代品,輕鬆管理容器和 K8s(支持 M1 芯片)
- 5 分鐘帶你瞭解 DevOps 的發展史
- 2021 年 Top 8 開源 Kubernetes 安全工具
- Docker確確實實改變了世界!
- 7 張圖帶你搞懂 Kubernetes Flannel 高性能網絡插件的兩種常用工作模式
- Kubernetes 常見運維技巧
- 世界最著名的 16 個開源軟件基金會,你認識哪幾個呢?
- 製作一個超級精簡的 Docker 鏡像只需7步