選取您的 Cookie 偏好設定

我們使用提供自身網站和服務所需的基本 Cookie 和類似工具。我們使用效能 Cookie 收集匿名統計資料,以便了解客戶如何使用我們的網站並進行改進。基本 Cookie 無法停用,但可以按一下「自訂」或「拒絕」以拒絕效能 Cookie。

如果您同意,AWS 與經核准的第三方也會使用 Cookie 提供實用的網站功能、記住您的偏好設定,並顯示相關內容,包括相關廣告。若要接受或拒絕所有非必要 Cookie,請按一下「接受」或「拒絕」。若要進行更詳細的選擇,請按一下「自訂」。

AWS 使用 Kubernetes 服務帳戶授予 Kubernetes 工作負載存取權

焦點模式
AWS 使用 Kubernetes 服務帳戶授予 Kubernetes 工作負載存取權 - Amazon EKS

協助改善此頁面

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

若要提供此使用者指南,請選擇位於每個頁面右窗格中的 GitHub 上編輯此頁面連結。

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

協助改善此頁面

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

若要提供此使用者指南,請選擇位於每個頁面右窗格中的 GitHub 上編輯此頁面連結。

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

管理服務帳戶服務帳戶的 IAM 角色了解 EKS Pod Identity 如何授予 Pod 對 AWS 服務的存取權

服務帳戶字符

Kubernetes 版本預設會啟用 BoundServiceAccountTokenVolume 功能。此功能允許在 Kubernetes 上執行的工作負載請求對象、時間和金鑰綁定的 JSON Web 字符,從而提升服務帳戶字符的安全性。服務帳戶字符的過期時間為一小時。在舊版 Kubernetes 中,權杖沒有過期。這表示仰賴這些字符的客戶端必須在一小時內重新整理字符。下列 Kubernetes 用戶端 SDKs 會在所需的時間範圍內自動重新整理權杖:

  • Go 版本 0.15.7 和更新版本

  • Python 版本 12.0.0 和更新版本

  • Java 版本 9.0.0 和更新版本

  • JavaScript 版本 0.10.3 和更新版本

  • Ruby master 分支

  • Haskell 版本 0.3.0.0

  • C# 版本 7.0.5和更新版本

如果工作負載使用較早的客戶端版本,則必須進行更新。為了讓用戶端順利遷移至較新的限時服務帳戶字符,Kubernetes 會在預設的 1 小時內,將延長的到期期間新增至服務帳戶字符。針對 Amazon EKS 叢集,延長的到期期間為 90 天。Amazon EKS 叢集的 Kubernetes API 伺服器會拒絕具有超過 90 天權杖的請求。我們建議您檢查應用程式及其相依性,以確保 Kubernetes 用戶端開發套件與先前列出的版本相同或為更新版本。

當 API 服務器收到使用超過一小時的字符的請求時,它會使用 annotations.authentication.k8s.io/stale-token 註釋 API 稽核日誌事件。註釋的值如下範例所示:

subject: system:serviceaccount:common:fluent-bit, seconds after warning threshold: 4185802.

如果您的叢集啟用了控制平面記錄,則註釋位於稽核日誌中。您可以使用下列 CloudWatch Logs Insights 查詢來識別 Amazon EKS 叢集中正在使用過時字符的所有 Pod:

fields @timestamp |filter @logStream like /kube-apiserver-audit/ |filter @message like /seconds after warning threshold/ |parse @message "subject: *, seconds after warning threshold:*\"" as subject, elapsedtime

subject 是指 Pod 使用的服務帳戶。elapsedtime 表示讀取最新字符後的經過時間(以秒為單位)。當 elapsedtime 超過 90 天 (7,776,000 秒),對 API 伺服器的請求將遭到拒絕。您應該主動更新應用程式的 Kubernetes 用戶端 SDK,以使用先前列出的其中一個會自動重新整理權杖的版本。如果使用的 服務帳戶字符接近 90 天,而且您沒有足夠的時間在字符過期之前更新用戶端 SDK 版本,則可以終止現有的 Pod 並建立新的 Pod。這會導致重新擷取服務帳戶字符,進而給您額外的 90 天來更新的客戶端版本 SDK。

如果 Pod 是部署的一部分,建議終止 Pod 同時保持高可用性的方式是使用下列命令執行推展。使用您的部署名稱替換 my-deployment (我的部署)。

kubectl rollout restart deployment/my-deployment

叢集附加元件

下列叢集附加元件已更新為使用 Kubernetes 用戶端 SDKs以自動重新擷取服務帳戶字符。建議您確保已在叢集上安裝列出的版本或更新版本。

將 AWS Identity and Access Management 許可授予 Amazon Elastic Kubernetes Service 叢集上的工作負載

Amazon EKS 提供兩種方式,將 AWS Identity and Access Management 許可授予在 Amazon EKS 叢集中執行的工作負載:服務帳戶的 IAM 角色,以及 EKS Pod 身分

服務帳戶的 IAM 角色

服務帳戶的 IAM 角色 (IRSA) 會設定在 上執行的 Kubernetes 應用程式, AWS 並具有精細的 IAM 許可,以存取各種其他 AWS 資源,例如 Amazon S3 儲存貯體、Amazon DynamoDB 資料表等。您可以在同一個 Amazon EKS 叢集中同時執行多個應用程式,並確保每個應用程式只有其所需的最低許可集。IRSA 的建置旨在支援 支援的各種 Kubernetes 部署選項, AWS 例如 Amazon EKS、Amazon EKS Anywhere、Red Hat OpenShift Service on AWS,以及 Amazon EC2 執行個體上的自我管理 Kubernetes 叢集。因此,IRSA 是使用基礎 AWS 服務如 IAM 建置,且並未直接依賴 Amazon EKS 服務和 EKS API。如需詳細資訊,請參閱服務帳戶的 IAM 角色

EKS Pod 身分

EKS Pod Identity 為叢集管理員提供了簡化的工作流程,用於驗證應用程式以存取各種其他 AWS 資源,例如 Amazon S3 儲存貯體、Amazon DynamoDB 資料表等。EKS Pod 身分識別僅適用於 EKS,因此可簡化叢集管理員設定 Kubernetes 應用程式以取得 IAM 許可的方式。這些許可現在可以直接透過 EKS API 和 AWS CLI 輕鬆設定 AWS Management Console較少的步驟,而且在任何 Kubernetes 物件中,叢集內不需要採取任何動作。叢集管理員不需要在 EKS 和 IAM 服務之間切換,或使用特權 IAM 操作來設定應用程式所需的許可。IAM 角色現在可跨多個叢集使用,無需在建立新叢集時更新角色信任政策。EKS Pod 身分識別提供的 IAM 憑證包含角色工作階段標籤,並具有叢集名稱、命名空間、服務帳戶名稱等屬性。角色工作階段標籤可讓管理員撰寫單一角色,以根據相符的標籤允許存取 AWS 資源,進而跨服務帳戶運作。如需詳細資訊,請參閱了解 EKS Pod Identity 如何授予 Pod 對 AWS 服務的存取權

比較 EKS Pod 身分識別和 IRSA

整體上來說,EKS Pod 身分識別和 IRSA 都可讓您將 IAM 許可授予在 Kubernetes 叢集上執行的應用程式。但是,它們在設定方式、支援的限制和啟用的功能完全不同。下面,我們會比較兩個解決方案的一些關鍵面向。

屬性 EKS Pod 身分識別 IRSA

角色擴充性

您必須設定每個角色一次,才能與新推出的 Amazon EKS 服務主體 pods.eks.amazonaws.com 建立信任。在此一次性步驟之後,您不需要在每次在新叢集中使用角色的信任政策時更新。

每次您想要在新叢集中使用角色時,都必須使用新的 EKS 叢集 OIDC 提供者端點來更新 IAM 角色的信任政策。

叢集可擴展性

EKS Pod Identity 不需要使用者設定 IAM OIDC 供應商,因此不適用此限制。

每個 EKS 叢集都有與其相關聯的 OpenID Connect (OIDC) 發行者 URL。若要使用 IRSA,需要為 IAM 中的每個 EKS 叢集建立唯一的 OpenID Connect 提供者。IAM 每個 AWS 帳戶的預設全域限制為 100 個 OIDC 提供者。如果您計劃為每個具有 IRSA AWS 的帳戶擁有超過 100 個 EKS 叢集,則您將達到 IAM OIDC 提供者限制。

角色可擴展性

EKS Pod Identity 不需要使用者在信任政策中定義 IAM 角色和服務帳戶之間的信任關係,因此不適用此限制。

在 IRSA 中,您可以在角色的信任政策中定義 IAM 角色和服務帳戶之間的信任關係。根據預設,信任政策大小的長度為 2048。這表示您通常可以在單一信任政策中定義 4 個信任關係。雖然您可以提高信任政策長度限制,但在單一信任政策中,您通常只能使用最多 8 個信任關係。

角色可重複使用性

AWS EKS Pod Identity 提供的 STS 臨時憑證包括角色工作階段標籤,例如叢集名稱、命名空間、服務帳戶名稱。角色工作階段標籤可讓管理員撰寫單一 IAM 角色,該角色可以與多個服務帳戶搭配使用,具有不同的有效許可,方法是允許根據附加的資源來存取 AWS 資源。這也稱為屬性型存取控制 (ABAC)。如需詳細資訊,請參閱根據標籤授予 Pod 對 {aws} 資源的存取權

AWS 不支援 STS 工作階段標籤。您可以在叢集之間重複使用角色,但是每個 Pod 都會收到該角色的所有許可。

支援的環境

EKS Pod 身分識別僅適用於 Amazon EKS。

IRSA 可用於 Amazon EKS、Amazon EKS Anywhere、Red Hat OpenShift Service on AWS,以及 Amazon EC2 執行個體上的自我管理 Kubernetes 叢集。

支援 EKS 版本

EKS Kubernetes 版本 1.24 或更新版本。如需特定平台版本,請參閱 EKS Pod 身分識別叢集版本

所有支援的 EKS 叢集版本。

隱私權網站條款Cookie 偏好設定
© 2025, Amazon Web Services, Inc.或其附屬公司。保留所有權利。