服務帳戶

本頁介紹 Kubernetes 中的 ServiceAccount 物件，提供關於服務帳戶如何運作、使用案例、限制、替代方案以及額外指南資源的連結資訊。

什麼是服務帳戶？

服務帳戶是一種非人類帳戶類型，在 Kubernetes 中，它在 Kubernetes 叢集中提供獨特的身份。應用程式 Pod、系統元件以及叢集內外的實體可以使用特定 ServiceAccount 的憑證來識別為該 ServiceAccount。此身份在各種情況下都很有用，包括向 API 伺服器進行身份驗證或實作基於身份的安全性策略。

服務帳戶以 API 伺服器中的 ServiceAccount 物件形式存在。服務帳戶具有以下屬性

• 命名空間： 每個服務帳戶都繫結到 Kubernetes 命名空間。每個命名空間在建立時都會取得 預設 ServiceAccount。

• 輕量： 服務帳戶存在於叢集中，並在 Kubernetes API 中定義。您可以快速建立服務帳戶以啟用特定任務。

• 可攜式： 複雜容器化工作負載的組態套件可能包含系統元件的服務帳戶定義。服務帳戶的輕量特性和命名空間身份使組態具有可攜性。

服務帳戶與使用者帳戶不同，使用者帳戶是叢集中經過身份驗證的人類使用者。預設情況下，使用者帳戶不存在於 Kubernetes API 伺服器中；相反地，API 伺服器將使用者身份視為不透明資料。您可以使用多種方法以使用者帳戶身分進行身份驗證。某些 Kubernetes 發行版本可能會新增自訂擴充 API，以在 API 伺服器中表示使用者帳戶。

預設服務帳戶

當您建立叢集時，Kubernetes 會自動為叢集中每個命名空間建立名為 預設 的 ServiceAccount 物件。每個命名空間中的 預設 服務帳戶預設不會取得任何權限，除了 Kubernetes 授予所有已驗證主體的 預設 API 探索權限 (如果已啟用基於角色的存取控制 (RBAC))。如果您刪除命名空間中的 預設 ServiceAccount 物件，控制平面 會將其替換為新的。

如果您在命名空間中部署 Pod，而且您沒有手動將 ServiceAccount 指派給 Pod，則 Kubernetes 會將該命名空間的 預設 ServiceAccount 指派給 Pod。

Kubernetes 服務帳戶的使用案例

作為一般準則，您可以使用服務帳戶在以下情境中提供身份

• 您的 Pod 需要與 Kubernetes API 伺服器通訊，例如在以下情況中
  • 提供對儲存在密鑰中的敏感資訊的唯讀存取權。
  • 授予跨命名空間存取權，例如允許命名空間 example 中的 Pod 讀取、列出和監看 kube-node-lease 命名空間中的 Lease 物件。
• 您的 Pod 需要與外部服務通訊。例如，工作負載 Pod 需要商業雲端 API 的身份，而商業提供者允許設定適當的信任關係。
• 使用 imagePullSecret 向私有映像檔登錄檔進行身份驗證.
• 外部服務需要與 Kubernetes API 伺服器通訊。例如，在 CI/CD 管線中作為叢集的一部分進行身份驗證。
• 您在叢集中使用協力廠商安全性軟體，該軟體依賴不同 Pod 的 ServiceAccount 身份將這些 Pod 分組到不同的內容中。

如何使用服務帳戶

若要使用 Kubernetes 服務帳戶，請執行以下操作

1. 使用 Kubernetes 用戶端 (例如 kubectl) 或定義物件的資訊清單建立 ServiceAccount 物件。

2. 使用授權機制 (例如 RBAC) 授予 ServiceAccount 物件權限。

3. 在 Pod 建立期間將 ServiceAccount 物件指派給 Pod。

   如果您要使用來自外部服務的身份，請擷取 ServiceAccount 權杖並從該服務中使用它。

如需指示，請參閱 設定 Pod 容器的服務帳戶。

授予 ServiceAccount 權限

您可以使用內建 Kubernetes 基於角色的存取控制 (RBAC) 機制來授予每個服務帳戶所需的最少權限。您建立一個角色 (授予存取權)，然後將角色繫結到您的 ServiceAccount。RBAC 可讓您定義一組最小權限，以便服務帳戶權限遵循最小權限原則。使用該服務帳戶的 Pod 不會取得超出正常運作所需的權限。

如需指示，請參閱 ServiceAccount 權限。

使用 ServiceAccount 的跨命名空間存取

您可以使用 RBAC，允許一個命名空間中的服務帳戶對叢集中不同命名空間的資源執行操作。例如，假設您在 dev 命名空間中有一個服務帳戶和 Pod，並且您希望您的 Pod 能夠看到在 maintenance 命名空間中執行的 Job。您可以建立一個 Role 物件，授予列出 Job 物件的權限。然後，您需要在 maintenance 命名空間中建立 RoleBinding 物件，將 Role 繫結到 ServiceAccount 物件。現在，dev 命名空間中的 Pod 就可以使用該服務帳戶列出 maintenance 命名空間中的 Job 物件。

將 ServiceAccount 指派給 Pod

若要將 ServiceAccount 指派給 Pod，您需要在 Pod 規範中設定 spec.serviceAccountName 欄位。然後 Kubernetes 會自動為該 ServiceAccount 提供憑證給 Pod。在 v1.22 及更新版本中，Kubernetes 會使用 TokenRequest API 取得一個自動輪換的短期權杖，並將該權杖掛載為投射卷。

預設情況下，無論是 default ServiceAccount 還是您指定的自訂 ServiceAccount，Kubernetes 都會為 Pod 提供已指派的 ServiceAccount 憑證。

若要防止 Kubernetes 自動注入指定 ServiceAccount 或 default ServiceAccount 的憑證，請在您的 Pod 規範中將 automountServiceAccountToken 欄位設定為 false。

在 1.22 之前的版本中，Kubernetes 會以 Secret 的形式向 Pod 提供長期有效的靜態權杖。

手動檢索 ServiceAccount 憑證

如果您需要 ServiceAccount 的憑證以掛載到非標準位置，或用於非 API 伺服器的對象，請使用以下方法之一

• TokenRequest API（建議）：從您自己的應用程式碼中請求一個短期服務帳戶權杖。權杖會自動過期，並可在過期時輪換。如果您有不支援 Kubernetes 的舊版應用程式，您可以在同一個 Pod 中使用 sidecar 容器來取得這些權杖，並使其可供應用程式工作負載使用。
• 權杖卷投射（也建議）：在 Kubernetes v1.20 及更新版本中，使用 Pod 規範告知 kubelet 將服務帳戶權杖作為投射卷新增到 Pod 中。投射權杖會自動過期，並且 kubelet 會在權杖過期前輪換權杖。
• Service Account 權杖 Secret（不建議）：您可以將服務帳戶權杖作為 Kubernetes Secret 掛載到 Pod 中。這些權杖不會過期，也不會輪換。在 v1.24 之前的版本中，會為每個服務帳戶自動建立一個永久權杖。由於與靜態、長期有效的憑證相關的風險，因此不再建議使用此方法，尤其是在大規模部署時。LegacyServiceAccountTokenNoAutoGeneration 功能閘道（從 Kubernetes v1.24 到 v1.26 預設啟用）阻止 Kubernetes 自動為 ServiceAccount 建立這些權杖。此功能閘道已在 v1.27 中移除，因為它已提升為 GA 狀態；您仍然可以手動建立無限期服務帳戶權杖，但應考慮安全性影響。

限制對 Secret 的存取（已棄用）

Kubernetes 提供了一個名為 kubernetes.io/enforce-mountable-secrets 的註解，您可以將其新增到您的 ServiceAccount。當套用此註解時，ServiceAccount 的 Secret 只能掛載到指定的資源類型上，從而增強您叢集的安全態勢。

您可以使用 Manifest 將註解新增到 ServiceAccount

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    kubernetes.io/enforce-mountable-secrets: "true"
  name: my-serviceaccount
  namespace: my-namespace

當此註解設定為 "true" 時，Kubernetes 控制平面會確保來自此 ServiceAccount 的 Secret 受到某些掛載限制。

1. 在 Pod 中作為卷掛載的每個 Secret 的名稱都必須出現在 Pod 的 ServiceAccount 的 secrets 欄位中。
2. 在 Pod 中使用 envFrom 參照的每個 Secret 的名稱也必須出現在 Pod 的 ServiceAccount 的 secrets 欄位中。
3. 在 Pod 中使用 imagePullSecrets 參照的每個 Secret 的名稱也必須出現在 Pod 的 ServiceAccount 的 secrets 欄位中。

透過理解和強制執行這些限制，叢集管理員可以維護更嚴格的安全設定檔，並確保只有適當的資源才能存取 Secret。

驗證服務帳戶憑證

ServiceAccount 使用簽署的 JSON Web Tokens (JWT) 向 Kubernetes API 伺服器以及任何存在信任關係的其他系統進行身份驗證。根據權杖的發行方式（使用 TokenRequest 的限時權杖或使用 Secret 的舊版機制），ServiceAccount 權杖也可能具有到期時間、對象以及權杖開始有效的時間。當充當 ServiceAccount 的用戶端嘗試與 Kubernetes API 伺服器通訊時，用戶端會在 HTTP 請求中包含 Authorization: Bearer <token> 標頭。API 伺服器會按如下方式檢查該持有者權杖的有效性

1. 檢查權杖簽章。
2. 檢查權杖是否已過期。
3. 檢查權杖宣告中的物件參照目前是否有效。
4. 檢查權杖目前是否有效。
5. 檢查對象宣告。

TokenRequest API 為 ServiceAccount 產生繫結權杖。此繫結與充當該 ServiceAccount 的用戶端（例如 Pod）的生命週期相關聯。有關繫結 Pod 服務帳戶權杖的 JWT 結構描述和酬載範例，請參閱權杖卷投射。

對於使用 TokenRequest API 發行的權杖，API 伺服器也會檢查使用 ServiceAccount 的特定物件參照是否仍然存在，並透過該物件的唯一 ID 進行比對。對於作為 Secret 掛載在 Pod 中的舊版權杖，API 伺服器會根據 Secret 檢查權杖。

有關身份驗證過程的更多資訊，請參閱身份驗證。

在您自己的程式碼中驗證服務帳戶憑證

如果您的服務需要驗證 Kubernetes 服務帳戶憑證，您可以使用以下方法

• TokenReview API（建議）
• OIDC 探索

Kubernetes 專案建議您使用 TokenReview API，因為此方法會使繫結到 API 物件（例如 Secret、ServiceAccount、Pod 或節點）的權杖在這些物件刪除時失效。例如，如果您刪除包含投射 ServiceAccount 權杖的 Pod，叢集會立即使該權杖失效，而 TokenReview 會立即失敗。如果您改用 OIDC 驗證，您的用戶端會繼續將權杖視為有效，直到權杖達到其到期時間戳記。

您的應用程式應始終定義其接受的對象，並應檢查權杖的對象是否與應用程式期望的對象相符。這有助於最大限度地縮小權杖的範圍，使其只能在您的應用程式中使用，而不能在其他任何地方使用。

替代方案

• 使用其他機制發行您自己的權杖，然後使用Webhook 權杖身份驗證來使用您自己的驗證服務驗證持有者權杖。
• 為 Pod 提供您自己的身份。

  • 使用 SPIFFE CSI 驅動程式外掛程式將 SPIFFE SVID 作為 X.509 憑證對提供給 Pod.

    🛇 此項目連結到非 Kubernetes 本身一部分的第三方專案或產品。更多資訊

  • 使用服務網格（例如 Istio）向 Pod 提供憑證.

• 從叢集外部向 API 伺服器進行身份驗證，而無需使用服務帳戶權杖
  • 設定 API 伺服器以接受來自您身份提供者的 OpenID Connect (OIDC) 權杖.
  • 使用使用外部身份和存取管理 (IAM) 服務（例如來自雲端供應商）建立的服務帳戶或使用者帳戶，向您的叢集進行身份驗證。
  • 將 CertificateSigningRequest API 與用戶端憑證搭配使用.
• 設定 kubelet 以從映像登錄檔中檢索憑證.
• 使用裝置外掛程式存取虛擬可信任平台模組 (TPM)，然後允許使用私鑰進行身份驗證。

下一步

• 瞭解如何以叢集管理員身分管理您的 ServiceAccount。
• 瞭解如何將 ServiceAccount 指派給 Pod。
• 閱讀ServiceAccount API 參考。