編輯

共用方式為

Kubernetes 工作負載身分識別和存取

Microsoft Entra ID
Azure Kubernetes Service (AKS)

本文說明 Amazon Elastic Kubernetes Service （Amazon EKS） 和 Azure Kubernetes Service （AKS） 如何為 Kubernetes 工作負載提供身分識別，以存取雲端平台服務。 如需 Amazon Web Services （AWS） 身分識別與存取管理 （IAM） 和 Microsoft Entra 標識碼的詳細比較，請參閱：

本指南說明 AKS 叢集、內建服務和附加元件 如何使用受控識別 來存取 Azure 資源，例如負載平衡器和受控磁碟。 本文也會示範如何使用 Microsoft Entra 工作負載 ID，讓 AKS 工作負載可以存取 Azure 資源，而不需要 連接字串、存取密鑰或用戶認證。

注意

本文是一系列文章的一部分，可協助熟悉 Amazon EKS 的專業人員瞭解 Azure Kubernetes Service （AKS）。

Amazon EKS 身分識別與存取管理

Amazon EKS 有兩個原生選項可從 Kubernetes Pod 內呼叫 AWS 服務：服務帳戶的 IAM 角色，以及 Amazon EKS 服務連結角色。

服務帳戶 的 IAM 角色會將 IAM 角色與 Kubernetes 服務帳戶產生關聯。 此服務帳戶會將 AWS 許可權提供給任何使用服務帳戶之 Pod 中的容器。 服務帳戶的 IAM 角色提供下列優點：

  • 最低許可權：您不需要為節點上的 Pod 提供節點 IAM 角色的擴充許可權，即可呼叫 AWS API。 您可以將 IAM 許可權限定為服務帳戶，而且只有使用該服務帳戶的 Pod 可以存取這些許可權。 這項功能也不需要第三方解決方案，例如 kiam 或 kube2iam。

  • 認證隔離：容器只能擷取與其所屬服務帳戶相關聯之 IAM 角色的認證。 容器永遠無法存取屬於另一個 Pod 之另一個容器的認證。

  • 可稽核性： Amazon CloudTrail 提供存取權和事件記錄，以協助確保回顧性稽核。

Amazon EKS 服務連結角色 是直接連結至 Amazon EKS 的唯一 IAM 角色。 Amazon EKS 預先定義服務連結角色，並包含代表角色呼叫其他 AWS 服務所需的所有許可權。 針對 Amazon EKS 節點 IAM 角色，Amazon EKS 節點kubelet精靈會代表節點呼叫 AWS API。 節點會從 IAM 實例設定檔和相關聯的原則取得這些 API 呼叫的許可權。

AKS 叢集受控識別

AKS 叢集需要身分識別才能存取 Azure 資源，例如負載平衡器和受控磁碟。 此身分識別可以是受控識別或服務主體。 根據預設，建立 AKS 叢集會自動建立 系統指派的受控識別。 Azure 平台會管理身分識別，您不需要布建或輪替任何秘密。 如需Microsoft Entra 受控識別的詳細資訊，請參閱 Azure 資源的受控識別。

AKS 不會自動建立 服務主體 ，因此如果您想要使用服務主體，則必須建立它。 服務主體最終會過期，您必須更新它，才能讓叢集正常運作。 管理服務主體會增加複雜性，因此更容易使用受控識別。

受控識別基本上是服務主體的包裝函式，可簡化管理。 相同的許可權需求同時適用於服務主體和受控識別。 受控識別使用憑證式驗證。 每個受控識別認證都有 90 天的到期日，並在 45 天后輪替。

AKS 同時使用系統指派和使用者指派的受控識別類型，而且這些身分識別是不可變的。 當您建立或使用 AKS 虛擬網路、連結的 Azure 磁碟、靜態 IP 位址、路由表或使用者指派kubelet的身分識別與節點資源群組外部的資源時，Azure CLI 會自動新增角色指派。

如果您使用其他方法來建立 AKS 叢集，例如 Bicep 範本、Azure Resource Manager 範本或 Terraform 模組，則必須使用叢集受控識別的主體標識符來執行角色指派。 AKS 叢集身分識別在虛擬網路內的子網上必須至少有 網路參與者 角色。 若要定義自定義角色，而不是使用內建的網路參與者角色，您需要下列許可權：

  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read

當叢集身分識別需要存取現有的資源時，例如當您將 AKS 叢集部署到現有的虛擬網路時，您應該使用使用者指派的受控識別。 如果您使用系統指派的控制平面身分識別，資源提供者無法在建立叢集之前取得其主體標識碼，因此在叢集布建之前無法建立適當的角色指派。

受控識別摘要

AKS 會針對內建服務和附加元件使用下列 使用者指派的受控識別 。

身分識別 名稱 使用案例 預設權限 自備識別
控制平面 AKS 叢集名稱 管理叢集資源，包括輸入負載平衡器和 AKS 管理的公用 IP、叢集自動調整程式，以及 Azure 磁碟和 Azure 檔案 CSI 驅動程式 節點資源群組的參與者角色 支援
Kubelet AKS 叢集名稱 - agentpool 使用 Azure Container Registry 進行驗證 NA （適用於 Kubernetes v1.15+） 支援
附加元件 HTTPApplicationRouting 管理所需的網路資源 節點資源群組的讀者角色、DNS 區域的參與者角色 No
附加元件 輸入應用程式閘道 管理所需的網路資源 節點資源群組的參與者角色 No
附加元件 omsagent 將 AKS 計量傳送至 Azure 監視器 監視計量發行者角色 No
附加元件 Virtual-Node (ACIConnector) 管理 Azure 容器執行個體 所需的網路資源 節點資源群組的參與者角色 No

如需詳細資訊，請參閱在 Azure Kubernetes Service 中使用受控識別。

適用於 Kubernetes 的 Microsoft Entra 工作負載 ID

Kubernetes 工作負載需要Microsoft Entra 應用程式認證，才能存取 Microsoft Entra 受保護的資源，例如 Azure 金鑰保存庫 和 Microsoft Graph。 開發人員常見的挑戰是管理秘密和認證，以保護解決方案的不同元件之間的通訊。

kubernetes 的 Microsoft Entra 工作負載 ID 不需要管理認證，才能存取 Azure Cosmos DB、Azure 金鑰保存庫 或 Azure Blob 儲存體 等雲端服務。 AKS 裝載的工作負載應用程式可以使用 Microsoft Entra 工作負載 ID 來存取 Azure 受控服務，方法是使用Microsoft Entra 安全性令牌，而不是明確認證，例如 連接字串、使用者名稱和密碼或主鍵。

如下圖所示，Kubernetes 叢集會成為向 Kubernetes 服務帳戶發出令牌的安全性令牌簽發者。 您可以將這些令牌設定為在 entra 應用程式Microsoft信任。 然後，您可以使用 Azure 身分識別 SDK 或 Microsoft 驗證連結庫 （MSAL） 來交換令牌，以交換令牌Microsoft Entra 存取令牌。

此圖顯示 Azure 中 Pod 受控識別的簡化工作流程。

  1. 代理程式會將 kubelet 服務帳戶令牌投影到工作負載的可設定檔案路徑。
  2. Kubernetes 工作負載會將投影、已簽署的服務帳戶令牌傳送至 Microsoft Entra 標識符，並要求存取令牌。
  3. Microsoft Entra ID 會使用 OIDC 探索檔來檢查使用者定義受控識別或已註冊應用程式的信任，並驗證傳入令牌。
  4. Microsoft Entra ID 會發出安全性存取令牌。
  5. Kubernetes 工作負載會使用 Microsoft Entra 存取令牌來存取 Azure 資源。

Microsoft Entra 工作負載 ID Kubernetes 的同盟目前僅支援Microsoft Entra 應用程式，但相同的模型可能會延伸到 Azure 受控識別。

如需 Microsoft Entra 工作負載 ID的詳細資訊、自動化和檔，請參閱：

範例工作負載

此範例工作負載會在 AKS 叢集上執行前端和後端服務。 工作負載服務會使用 Microsoft Entra 工作負載 ID 來存取下列 Azure 服務，方法是使用 Microsoft Entra 安全性令牌：

  • Azure Key Vault
  • Azure Cosmos DB
  • Azure 儲存體帳戶
  • Azure 服務匯流排命名空間

必要條件

  1. 設定已啟用 OIDC 簽發者的 AKS 叢集。
  2. 安裝變動許可 Webhook。
  3. 建立工作負載的 Kubernetes 服務帳戶。
  4. 建立Microsoft Entra 應用程式，如快速入門所示。
  5. 將具有適當許可權的角色指派給所需的 Microsoft Entra 註冊應用程式。
  6. 在 Microsoft Entra 應用程式與服務帳戶簽發者和主體之間建立同盟身分識別認證 。
  7. 將工作負載應用程式部署至 AKS 叢集。

Microsoft Entra 工作負載 ID 訊息流程

AKS 應用程式會從 AKS 叢集的 OIDC 簽發者 取得其服務帳戶的安全性令牌。 Microsoft Entra 工作負載 ID 交換安全性令牌與 Microsoft Entra ID 所發行的安全性令牌，而應用程式會使用 Microsoft Entra ID 發行的安全性令牌來存取 Azure 資源。

下圖顯示前端和後端應用程式如何取得 Microsoft Entra 安全性令牌，以使用 Azure 平臺即服務 （PaaS） 服務。

此圖顯示使用 Microsoft Entra 工作負載 ID 的範例應用程式。

下載此架構的 Visio 檔案。

  1. Kubernetes 會根據 Pod 或部署規格，在節點上排程令牌給 Pod。
  2. Pod 會將 OIDC 簽發的令牌傳送至 Microsoft Entra 識別碼，以要求特定 appId 和資源Microsoft Entra 令牌。
  3. Microsoft Entra 識別碼會檢查應用程式上的信任，並驗證傳入令牌。
  4. Microsoft Entra ID 發出安全性令牌： {sub: appId, aud: requested-audience}。
  5. Pod 會使用 Microsoft Entra 令牌來存取目標 Azure 資源。

若要在 Kubernetes 叢集中使用 Microsoft Entra 工作負載 ID 端對端：

  1. 您可以設定 AKS 叢集來發行令牌，併發佈 OIDC 探索檔，以允許驗證這些令牌。
  2. 您可以設定 Microsoft Entra 應用程式來信任 Kubernetes 令牌。
  3. 開發人員會設定其部署，以使用 Kubernetes 服務帳戶來取得 Kubernetes 令牌。
  4. Microsoft Entra 工作負載 ID 交換 Kubernetes 令牌以取得 Microsoft Entra 令牌。
  5. AKS 叢集工作負載會使用 Microsoft Entra 令牌來存取受保護的資源，例如 Microsoft Graph。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主要作者：

其他投稿人：

若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。

下一步