編輯

共用方式為


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 Elastic Kubernetes Service (EKS) 提供原生選項,可用來管理 Kubernetes Pod 內的身分識別和存取管理。 這些選項包括服務帳戶的 IAM 角色和 Amazon EKS 服務連結角色。

服務帳戶的 IAM 角色

服務帳戶的 IAM 角色可讓您將 IAM 角色與 Kubernetes 服務帳戶產生關聯。 此關聯會將 AWS 許可權提供給任何使用服務帳戶之 Pod 內的容器。 針對服務帳戶使用IAM角色的優點如下:

  • 最低許可權:您可以將特定 IAM 許可權指派給服務帳戶,確保只有使用該服務帳戶的 Pod 可以存取這些許可權。 這樣就不需要為節點上的所有Pod授與節點IAM角色的擴充許可權,以提供更安全且更細微的方法。 此外,這項功能不需要第三方解決方案,例如 kube2iam。 如需詳細資訊,請參閱 服務帳戶的 IAM 角色

  • 認證隔離:Pod 中的每個容器只能擷取與其個別服務帳戶相關聯之 IAM 角色的認證。 此隔離可確保容器無法存取屬於不同Pod中另一個容器的認證。

  • 稽核能力:Amazon EKS 利用 Amazon CloudTrail 來提供存取和事件記錄,促進追溯稽核和合規性。

如需服務帳戶 IAM 角色的詳細資訊,請參閱 官方檔案

Amazon EKS 服務連結角色

Amazon EKS 服務連結角色是與 Amazon EKS 直接連結的唯一 IAM 角色。 這些預先定義的角色包含代表相關聯角色呼叫 AWS 服務所需的所有必要許可權。 Amazon EKS 的主要服務連結角色是 Amazon EKS 節點 IAM 角色

Amazon EKS 節點 kubelet 精靈會利用 Amazon EKS 節點 IAM 角色,代表節點對 AWS 服務進行 API 呼叫。 IAM 實例配置檔和相關聯的原則會提供這些 API 呼叫的許可權。 此設定可簡化EKS叢集中節點的IAM角色管理。

若要深入瞭解 Amazon EKS 服務連結角色,請流覽 官方檔

其他資訊

除了服務帳戶和 Amazon EKS 服務連結角色的 IAM 角色之外,Amazon EKS 還有管理身分識別和存取權的其他基本層面。

  1. Amazon EKS RBAC 授權:Amazon EKS 支援角色型存取控制 (RBAC),讓您定義叢集中 Kubernetes 資源更細緻的許可權。

  2. AWS 身分識別與存取管理 (IAM):IAM 提供 AWS 服務的完整身分識別管理解決方案,包括 EKS。 它可讓您建立和管理使用者、群組和角色,以控制對 EKS 資源的存取。

  3. Amazon EKS 安全組:Amazon EKS 可讓您將安全組規則套用至叢集中執行的 Pod,以控制輸入和輸出流量。

如需在 Amazon EKS 中管理身分識別和存取管理的詳細資訊,請參閱 官方 Amazon EKS 檔

AKS 叢集受控識別

Azure Kubernetes Service (AKS) 叢集需要 Microsoft Entra 身分識別,才能存取負載平衡器和受控磁碟等 Azure 資源。 Azure 資源的受控識別是授權從 AKS 叢集存取其他 Azure 服務的建議方式。

什麼是受控識別?

開發人員常見的挑戰是管理用來保護服務之間通訊的秘密、認證、憑證和密鑰。 受控識別 不需要開發人員管理這些認證。 受控識別可讓您驗證 AKS 叢集,而不需管理認證,或在程式代碼中包含認證。 使用受控識別時,您會將 Azure 角色型訪問控制 (Azure RBAC) 角色指派給身分識別,並將許可權授與 Azure 中的特定資源。

以下是兩種類型的受控識別:

  • 系統指派。 某些 Azure 資源,例如虛擬機可讓您直接在資源上啟用受控識別。 當您啟用系統指派的受控識別時:

    • 特殊類型的服務主體會在身分識別Microsoft Entra ID 中建立。 服務主體會系結至該 Azure 資源的生命週期。 刪除 Azure 資源時,Azure 會自動為您刪除服務主體。
    • 根據設計,只有 Azure 資源才能使用此身分識別來要求來自Microsoft Entra 識別碼的令牌。
    • 您可以授權受控識別存取一或多個服務。
    • 系統指派的服務主體名稱一律與其建立的 Azure 資源名稱相同。
  • 使用者指派。 您也可以建立受控識別作為獨立 Azure 資源。 您可以 建立使用者指派的受控識別,並將它指派給一或多個 Azure 資源。 當您啟用使用者指派的受控識別時:

    • 特殊類型的服務主體會在身分識別Microsoft Entra ID 中建立。 服務主體會與使用它的資源分開管理。
    • 使用者指派的身分識別可供多個資源使用。
    • 您可以授權受控識別存取一或多個服務。

如需兩種受控識別類型差異的詳細資訊,請參閱 受控識別類型

Azure Kubernetes Service 中的受控識別 (AKS)

這兩種類型的受控識別很類似,您可以使用任一類型來授權從 AKS 叢集存取 Azure 資源。 它們之間的主要差異在於,系統指派的受控識別與單一 Azure 資源相關聯,例如 AKS 叢集,而使用者指派的受控識別本身就是獨立的 Azure 資源。 如需受控識別類型差異的詳細資訊,請參閱 azure 資源 受控識別中的 受控識別類型

您可以搭配 AKS 叢集使用三種類型的受控識別:

  1. 系統指派的受控識別: 這種類型的受控識別與單一 Azure 資源相關聯,例如 AKS 叢集。 只有叢集的生命週期才會存在。

  2. 使用者指派的受控識別: 使用者指派的受控識別是獨立的 Azure 資源,可用來授權從 AKS 叢集存取其他 Azure 服務。 它會與叢集分開保存,而且可供多個 Azure 資源使用。

  3. 預先建立的 kubelet 受控識別: 這是可供 kubelet 用來存取 Azure 中其他資源的選擇性使用者指派身分識別。 如果未為 kubelet 指定使用者指派的受控識別,AKS 會在節點資源群組中建立使用者指派的 kubelet 身分識別。

AKS 如何使用受控識別?

當您部署 AKS 叢集時,會自動為您建立 系統指派的受控識別。 您也可以選擇使用 使用者指派的受控識別建立叢集。 叢集會使用此受控識別來要求來自 Microsoft Entra ID 的令牌,然後用來授權存取 Azure 中執行的其他資源。

藉由將 Azure RBAC 角色指派給受控識別,您可以授與叢集存取特定資源的許可權。 例如,您可以將受控識別指派為 Azure RBAC 角色,以允許其存取 Azure Key Vault 中的秘密。 如此一來,您可以輕鬆地授權存取叢集,而不需管理認證。

在 AKS 中使用受控識別

當您在 AKS 中使用受控識別時,不需要布建或輪替任何秘密。 Azure 會為您管理身分識別的認證。 這可讓您授權從應用程式存取權,而不需要管理任何其他秘密。

如果您已經有使用受控識別的 AKS 叢集,您可以將它更新為不同類型的受控識別。 不過,請注意,當控制平面元件切換至新的身分識別時,可能會有延遲。 此程式可能需要數小時的時間,而且在此期間,控制平面元件會繼續使用舊的身分識別,直到其令牌到期為止。

AKS 所使用的受控識別摘要

AKS 使用不同類型的受控識別來啟用各種內建服務和附加元件。 以下是 AKS 所使用的受控識別摘要:

身分識別 用例 默認許可權
控制平面 (系統指派) AKS 控制平面元件用來管理叢集資源,包括輸入負載平衡器、AKS 管理的公用IP、叢集自動調整程式、Azure 磁碟、檔案和 Blob CSI 驅動程式。 節點資源群組的參與者角色
Kubelet (使用者指派) 用於向 Azure Container Registry 進行驗證(ACR)。 N/A (適用於 Kubernetes v1.15+)
附加元件身分識別(例如 AzureNPM、AzureCNI 網路監視、Azure 原則、Calico 等) 這些附加元件不需要身分識別。 N/A
應用程式路由 管理 Azure DNS 和 Azure Key Vault 憑證。 Key Vault 秘密 Key Vault 的使用者角色、DNS 區域的 DNS 區域參與者角色、私人 DNS 區域的私人 DNS 區域參與者角色
輸入應用程式閘道 管理所需的網路資源。 節點資源群組的參與者角色
OMS 代理程式 用來將 AKS 計量傳送至 Azure 監視器。 監視計量發行者角色
虛擬節點 (ACI 連接器) 管理 Azure 容器實例所需的網路資源(ACI)。 節點資源群組的參與者角色
成本分析 用來收集成本配置數據。 N/A
工作負載身分識別(Microsoft Entra Workload ID) 可讓應用程式使用 Microsoft Entra 工作負載標識元安全地存取雲端資源。 N/A

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

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

Microsoft Entra 工作負載標識符 與 Kubernetes 整合,讓部署在 AKS 叢集上的工作負載存取 Azure Key Vault 和 Microsoft Graph 等受 Entra 保護的資源Microsoft。 它會使用 Kubernetes 原生的功能來與外部識別提供者同盟。 如需詳細資訊,請參閱 搭配 Azure Kubernetes Service使用 Microsoft Entra 工作負載標識符。

若要使用 Microsoft Entra 工作負載標識碼,您必須在 Kubernetes 內設定服務帳戶。 然後,Pod 會使用此服務帳戶安全地驗證和存取 Azure 資源。 Microsoft Entra 工作負載標識碼適用於 Azure 身分識別用戶端連結庫或Microsoft驗證連結庫 (MSAL) 集合,以及應用程式註冊。

若要充分利用 Kubernetes 叢集中的 Microsoft Entra Workload ID,您必須設定 AKS 叢集來發行令牌,併發佈 OIDC 探索檔以進行令牌驗證。 如需詳細資訊,請參閱 在 Azure Kubernetes Service上建立 OpenID Connect 提供者。

您也需要設定 Microsoft Entra 應用程式來信任 Kubernetes 令牌。 開發人員接著可以將部署設定為使用 Kubernetes 服務帳戶來取得令牌,然後藉由Microsoft Entra 工作負載標識符交換Microsoft Entra 令牌。 最後,AKS 叢集工作負載可以使用這些Microsoft Entra 令牌,安全地存取 Azure 中的受保護資源。

如下圖所示,Kubernetes 叢集會成為向 Kubernetes 服務帳戶發出令牌的安全性令牌簽發者。 您可以將這些令牌設定為在 entra 應用程式Microsoft信任。 然後,您可以使用 Azure 身分識別 SDKMicrosoft 驗證連結庫 (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 工作負載標識碼相關的詳細資訊、檔和自動化,請參閱下列資源:

範例工作負載

AKS 叢集上執行的範例工作負載包含前端和後端服務。 這些服務會使用 Microsoft Entra Workload ID 來存取 Azure 服務,包括 Azure Key Vault、Azure Cosmos DB、Azure 記憶體帳戶和 Azure 服務總線命名空間。 若要設定此範例工作負載,必須符合下列必要條件:

  1. 設定已啟用 OpenID Connect 簽發者Microsoft Entra 工作負載標識符 的 AKS 叢集。
  2. 在工作負載 命名空間中建立 Kubernetes 服務帳戶
  3. 建立 Microsoft Entra 使用者指派的受控識別註冊的應用程式
  4. 在 Microsoft Entra 受控識別或已註冊的應用程式與工作負載服務帳戶之間建立同盟身分識別認證。
  5. 將具有適當許可權的必要角色指派給 Microsoft Entra 受控識別或已註冊的應用程式。
  6. 部署工作負載,並使用工作負載身分識別驗證。

Microsoft Entra 工作負載 ID 訊息流程

在此範例工作負載中,前端和後端應用程式會取得 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。

下一步