本文已超過一年。較舊的文章可能包含過時的內容。檢查頁面中的資訊自發布以來是否已變得不正確。

Kubernetes 1.25：以使用者命名空間執行 Pod 的 Alpha 支援

作者：Rodrigo Campos (Microsoft), Giuseppe Scrivano (Red Hat) |

Kubernetes v1.25 引入了對使用者命名空間的支援。

這是運行 Kubernetes 中安全工作負載的重大改進。每個 Pod 將僅能存取系統上可用 UID 和 GID 的有限子集，從而增加新的安全層，以防止在同一系統上運行的其他 Pod 造成影響。

它是如何運作的？

在 Linux 上運行的進程最多可以使用 4294967296 個不同的 UID 和 GID。

使用者命名空間是 Linux 的一項功能，允許將容器中的一組使用者映射到主機中的不同使用者，從而限制進程可以有效使用的 ID。此外，在新使用者命名空間中授予的功能不適用於主機初始命名空間。

為什麼它很重要？

使用者命名空間很重要的原因主要有兩個

  • 提高安全性，因為它們限制了 Pod 可以使用的 ID，因此每個 Pod 可以在其自己獨立的環境中運行，並具有唯一的 ID。

  • 以更安全的方式啟用以 root 身份運行工作負載。

在使用者命名空間中，我們可以將 Pod 內部的 root 使用者映射到容器外部的非零 ID，容器認為它們以 root 身份運行，而從主機的角度來看，它們是常規的非特權 ID。

該進程可以保留通常僅限於特權 Pod 的功能，並以安全的方式執行此操作，因為在新使用者命名空間中授予的功能不適用於主機初始命名空間。

我該如何啟用使用者命名空間？

目前，使用者命名空間支援是選擇性加入的，因此您必須為 Pod 設定 pod spec 節下的 hostUsers 為 false 來啟用它

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

您也可以直接聯繫我們

  • GitHub / Slack: @rata @giuseppe