Kubernetes v1.33：從 Secret 到 Service Account：Kubernetes 映象拉取的演進

作者：Anish Ramasekar (Microsoft) |

Kubernetes 穩步發展，以減少對儲存在 API 中的長期憑據的依賴。這一轉變的一個典型例子是 Kubernetes Service Account (KSA) 令牌從長期、靜態的令牌過渡到具有 OpenID Connect (OIDC) 相容語義的臨時、自動輪換的令牌。這一進步使得工作負載能夠安全地向外部服務進行身份驗證，而無需永續性 Secret。

然而，仍然存在一個主要差距：映象拉取身份驗證。如今，Kubernetes 叢集依賴於儲存在 API 中的映象拉取 Secret，這些 Secret 是長期存在的且難以輪換；或者依賴於節點級別的 kubelet 憑據提供程式，這允許在節點上執行的任何 Pod 訪問相同的憑據。這帶來了安全和運營方面的挑戰。

為了解決這個問題，Kubernetes 正在引入針對 Kubelet 憑據提供程式的 Service Account 令牌整合，該功能目前處於 Alpha 階段。這一增強功能允許憑據提供程式使用特定於 Pod 的 Service Account 令牌來獲取映象倉庫憑據，然後 kubelet 可以使用這些憑據進行映象拉取——從而消除了對長期映象拉取 Secret 的需求。

映象拉取 Secret 的問題

目前，Kubernetes 管理員在處理私有容器映象拉取方面主要有兩種選擇：

  1. 儲存在 Kubernetes API 中的映象拉取 Secret

    • 這些 Secret 通常是長期有效的，因為它們難以輪換。
    • 它們必須顯式附加到 Service Account 或 Pod 上。
    • 拉取 Secret 的洩露可能導致未經授權的映象訪問。

  2. Kubelet 憑據提供程式

    • 這些提供程式在節點級別動態獲取憑據。
    • 在同一節點上執行的任何 Pod 都可以訪問相同的憑據。
    • 沒有按工作負載進行隔離，增加了安全風險。

這兩種方法都不符合最小許可權或臨時身份驗證的原則，給 Kubernetes 留下了安全隱患。

解決方案：針對 Kubelet 憑據提供程式的 Service Account 令牌整合

這項新增強功能使得 Kubelet 憑據提供程式能夠在獲取映象倉庫憑據時使用工作負載身份。憑據提供程式不再依賴於長期有效的 Secret，而是可以使用 Service Account 令牌來請求與特定 Pod 身份繫結的短期憑據。

這種方法提供了：

  • 特定於工作負載的身份驗證：映象拉取憑據的作用域限定於特定的工作負載。
  • 臨時憑據：令牌會自動輪換，消除了長期 Secret 帶來的風險。
  • 無縫整合：與現有的 Kubernetes 身份驗證機制配合工作，符合雲原生安全最佳實踐。

工作原理

1. 用於憑據提供程式的 Service Account 令牌

如果 kubelet 通訊的憑據提供程式已選擇接收用於映象拉取的 Service Account 令牌，那麼 kubelet 會為 Service Account 生成短期的、自動輪換的令牌。這些令牌符合 OIDC ID 令牌語義，並作為 CredentialProviderRequest 的一部分提供給憑據提供程式。然後，憑據提供程式可以使用此令牌向外部服務進行身份驗證。

2. 映象倉庫身份驗證流程

  • 當一個 Pod 啟動時，kubelet 會向一個憑據提供程式請求憑據。
  • 如果憑據提供程式已選擇接收令牌，kubelet 會為該 Pod 生成一個 Service Account 令牌。
  • Service Account 令牌包含在 CredentialProviderRequest 中，允許憑據提供程式進行身份驗證，並將其換取來自映象倉庫（例如 AWS ECR、GCP Artifact Registry、Azure ACR）的臨時映象拉取憑據。
  • 然後，kubelet 使用這些憑據代表 Pod 拉取映象。

這種方法的優點

  • 安全性：消除了長期有效的映象拉取 Secret，減少了攻擊面。
  • 精細的訪問控制：憑據與單個工作負載繫結，而不是整個節點或叢集。
  • 操作簡便性：管理員無需手動管理和輪換映象拉取 Secret。
  • 提高合規性：幫助組織滿足禁止在叢集中使用永續性憑據的安全策略。

接下來是什麼？

對於 Kubernetes v1.34，我們預計將該功能以 Beta 版本釋出，同時繼續收集使用者的反饋。

在接下來的版本中，我們將重點關注：

  • 實現快取機制，以提高令牌生成的效能。
  • 為憑據提供程式提供更多靈活性，使其能夠決定如何快取返回給 kubelet 的映象倉庫憑據。
  • 使該功能與“確保映象是透過 Secret 拉取的”協同工作，以確保在使用 Service Account 令牌進行身份驗證時，使用某個映象的 Pod 都有權訪問該映象。

你可以在 Kubernetes 文件的用於映象拉取的 Service Account 令牌頁面上了解更多關於此功能的資訊。

你也可以關注 KEP-4412 來跟蹤未來 Kubernetes 版本中的進展。

立即試用

要試用此功能：

  1. 確保你正在執行 Kubernetes v1.33 或更高版本。.
  2. 在 kubelet 上啟用 ServiceAccountTokenForKubeletCredentialProviders 特性門控。
  3. 確保憑據提供程式支援：修改或更新你的憑據提供程式，以使用 Service Account 令牌進行身份驗證。
  4. 更新憑據提供程式配置，透過配置 tokenAttributes 欄位來選擇為憑據提供程式接收 Service Account 令牌。
  5. 部署一個 Pod，該 Pod 使用憑據提供程式從私有映象倉庫拉取映象。

我們非常希望聽到你對這個功能的反饋。請透過 Kubernetes Slack 上的 #sig-auth-authenticators-dev 頻道與我們聯絡（如需邀請，請訪問 https://slack.k8s.io/）。

如何參與

如果你有興趣參與此功能的開發、分享反饋或參與任何其他正在進行的 SIG Auth 專案，請在 Kubernetes Slack 上的 #sig-auth 頻道與我們聯絡。

我們也歡迎你參加每兩週舉行一次的 SIG Auth 會議，會議在每隔一個星期三舉行。