本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
Kubernetes 1.25:對使用使用者名稱字空間執行 Pod 的 alpha 支援
Kubernetes v1.25 引入了對使用者名稱字空間的支援。
這對於在 Kubernetes 中執行安全工作負載而言是一個重大改進。每個 Pod 只能訪問系統上可用 UID 和 GID 的有限子集,從而增加了一個新的安全層,以保護其免受在同一系統上執行的其他 Pod 的影響。
它是如何工作的?
在 Linux 上執行的程序最多可以使用 4294967296 個不同的 UID 和 GID。
使用者名稱字空間是一項 Linux 功能,允許將容器中的一組使用者對映到主機上的不同使用者,從而限制程序可以有效使用的 ID。此外,在新的使用者名稱字空間中授予的能力(capabilities)並不適用於主機的初始名字空間。
為什麼它很重要?
使用者名稱字空間之所以重要,主要有兩個原因
提高安全性,因為它們限制了 Pod 可以使用的 ID,因此每個 Pod 都可以使用唯一的 ID 在其獨立的隔離環境中執行。
能夠以更安全的方式執行 root 工作負載。
在使用者名稱字空間中,我們可以將 Pod 內的 root 使用者對映到容器外的非零 ID,這樣容器就認為自己以 root 身份執行,而從主機的角度來看,它們只是一個常規的非特權 ID。
該程序可以保留通常僅限於特權 Pod 的能力,並且可以安全地做到這一點,因為在新的使用者名稱字空間中授予的能力不適用於主機的初始名字空間。
如何啟用使用者名稱字空間?
目前,使用者名稱字空間支援是可選的,因此你必須透過在 Pod 規約中將 hostUsers
設定為 false
來為 Pod 啟用它。
apiVersion: v1
kind: Pod
spec:
hostUsers: false
containers:
- name: nginx
image: docker.io/nginx
該功能受特性門控的保護,因此請確保啟用 UserNamespacesStatelessPodsSupport
門控後才能使用這一新功能。
執行時也必須支援使用者名稱字空間
containerd:計劃在 1.7 版本中提供支援。有關更多詳細資訊,請參閱 containerd issue #7063。
CRI-O:v1.25 已支援使用者名稱字空間。
目前尚無計劃在 cri-dockerd
中支援此功能。
我如何參與?
你可以透過多種方式聯絡 SIG Node
- Slack: #sig-node
- 郵件列表
- 開放的社群問題/PR
你也可以直接聯絡我們:
- GitHub / Slack: @rata @giuseppe