Azure Kubernetes Service （AKS） 的存取與身份選項

適用於: ✔️ AKS 自動化 ✔️ AKS 標準

AKS 在五種不同的情境中使用身份。 每個情境回答不同的問題，並擁有自己的配置模型。

對於大多數正式環境中的 AKS 工作負載，建議將 AKS Automatic 作為預設選項，因為它以適用於正式環境的平台基準為基礎，包含身分相關的預設設定，同時保留本文所述的相同 AKS 身分模型。

本文會簡要說明每種情境，解釋指引如何對應到 AKS Automatic 和 AKS Standard，並提供深入說明文件的連結。

AKS 中的五種身份情境

情境 可解答的問題 深入探討文件
A. Kubernetes 控制平面身份驗證 誰正在呼叫 Kubernetes API？ 叢集認證概念、 外部身份提供者
B. Kubernetes 控制平面授權 呼叫者在被認證到 Kubernetes API 後可以做什麼？ 叢集授權概念
C. AKS resource authorization （Azure Resource Manager） 誰可以在 Azure 層級對 AKS 資源執行操作，例如提取kubeconfig？ 限制對叢集設定檔的存取，Azure 內建角色
D. 叢集身分識別（cluster → Azure） AKS 叢集在 Azure 上如何代表你管理資源？ AKS 中的管理身份
E. Workload identity （pod → Azure） Pods 如何與 Azure 服務如 金鑰保存庫 或 Storage 進行認證？ Microsoft Entra 工作負載 ID概述

AKS Automatic 與 AKS Standard 中的身分識別態勢

本文中的五個身份情境同時適用於 AKS 自動與 AKS 標準。 主要差異在於作戰姿態：

  • AKS 自動版提供更多預先設定的身份與安全預設。
  • AKS Standard 提供更多手動控制，且需要更多設定選擇。

大多數生產工作負載的預設起點是 AKS Automatic，需要更深入的自訂平台配置時則使用 AKS Standard。

欲了解 AKS Automatic 的概覽，請參閱 Azure Kubernetes Service （AKS） Automatic 簡介。

AKS 自動與 AKS 標準身份態勢比較

識別區域 AKS 自動姿勢 AKS標準姿勢 瞭解更多資訊
Kubernetes API 認證 以 Microsoft Entra 整合為建議模型的生產環境導向預設值 可配置，包括本地帳號和 Entra 整合選項 叢集認證概念
Kubernetes API 授權 Azure RBAC 已預先設定為 Kubernetes 授權方式 本機帳戶優先與由叢集組態選取的授權模式 叢集授權概念
AKS 資源授權 在 AKS 資源操作上使用標準 Azure RBAC 模型 在 AKS 資源操作上使用標準 Azure RBAC 模型 控制對 kubeconfig 的存取
叢集身份 使用管理身份模型，並設定生產基線預設值 採用管理身份模型，並由操作員選擇設置 AKS 中的管理身份
工作負載身份識別 工作負載識別碼與 OIDC 發行者皆已預先設定 可選且由操作員設定 工作負載身分總覽

本文其餘部分將簡要介紹每個情境。

A. Kubernetes 控制平面身份驗證

Kubernetes 控制平面認證確立呼叫 Kubernetes API 伺服器的使用者或服務主體的身份。 AKS 支援：

  • Microsoft Entra ID（推薦）：使用 Entra ID 身份與群組登入叢集。 Microsoft Entra 整合會代表您佈建並輪替整合。 要啟用，請參見 使用 Microsoft Entra 整合。
  • 本地帳號：內建的叢集管理員憑證，可繞過 Entra ID。 我們建議在生產環境中關閉本地帳號。 請參閱 管理本地帳戶。
  • 外部身份提供者：使用非 Microsoft Entra ID 以外的 OIDC 合規身份提供者。 請參見 外部身份提供者認證。

大多數生產工作負載，建議先從 AKS Automatic 與 Microsoft Entra 整合開始。

欲深入了解 AKS 如何驗證 Kubernetes API 請求，請參閱 叢集認證概念。

B. Kubernetes 控制平面授權

呼叫者被認證至 Kubernetes API 後，AKS 會以兩種模型中的一種（或兩種）授權請求：

  • Kubernetes RBAC：由 API 伺服器評估的 Kubernetes 原生 Role、ClusterRole 和 RoleBinding 模型。 權限以 Kubernetes 物件的形式存在於叢集中。
  • Microsoft Entra ID 授權：AKS 授權 webhook 會利用 Azure 角色分配，將授權決策委派給 Microsoft Entra ID。 所有標準 Kubernetes API 資源都支援 Azure dataActions RBAC 角色指派，而自訂資源則支援帶有 Azure ABAC 條件的角色指派。 在 Microsoft Entra ID 中集中管理權限，從訂閱、管理群組或資源群組範圍內的單一角色指派管理多個叢集。

在 AKS Automatic 中，Azure RBAC for Kubernetes 授權已預先設定為生產準備預設態勢的一部分。

關於何時使用各模型的比較與指引，請參閱 叢集授權概念。

C. AKS resource authorization （Azure Resource Manager）

除了授權 Kubernetes API 的呼叫外，你還需要授權 Azure 層級的 AKS 資源操作。 最常見的例子是控制誰能拉取叢集 kubeconfig，這是獨立的 Azure 資源管理員操作，可以用 Azure RBAC 細緻管理。 此操作使用標準 Azure RBAC 對Microsoft.ContainerService資源提供者，與 Kubernetes API 授權分開，且對 AKS Automatic 與 AKS Standard 的適用方式相同。 更多資訊請參閱「限制對叢集設定檔的存取」以及 Azure 內建角色中的「內建角色」。

D. 叢集身分識別（cluster → Azure）

AKS 叢集使用 Azure 管理身份代表你操作 Azure 資源——例如建立負載平衡器、連接磁碟，或從 Azure 容器登錄檔拉取映像。 主要身份為：

  • 控制平面身份：叢集控制平面用來管理叢集的 Azure 資源。
  • Kubelet 身分識別：kubelet 在每個節點上用來驗證服務，例如 Azure Container Registry。
  • 附加元件/擴充身份：部分 AKS 附加元件與擴充功能使用自己的受管理身份。

AKS Automatic 保留相同的身份模型，同時透過預先設定的生產預設降低設置上的摩擦。

關於每種身份類型的詳細資訊，以及如何使用系統指派與使用者指派的身份，請參見 AKS 中的受管理身份。

E. Workload identity （pod → Azure）

工作負載身分識別可讓 AKS 叢集中執行的 Pod 向 Microsoft Entra 所保護的 Azure 服務 (例如 金鑰保存庫、儲存設備或 Cosmos DB) 進行驗證，無需在叢集中儲存祕密。 AKS 會使用Microsoft Entra 工作負載識別碼，該功能會將同盟的 Kubernetes 服務帳戶權杖投射到一個 Microsoft Entra 應用程式或使用者指派的受控身分識別中。

AKS 自動包含工作負載身分識別與 OIDC 發行者做為預先設定的預設值。 在 AKS 標準中，這些功能為可選且由操作員自行配置。

不要用已棄用的 Microsoft Entra Pod 管理身份 來處理新工作負載。

決策指南

Goal 請使用這些文件
先從適用於大多數工作負載的可投入生產環境身分識別基準開始 AKS Automatic 簡介
用 Microsoft Entra ID 登入叢集 啟用 Microsoft Entra 整合
在 Kubernetes API 中，管理誰能在多個叢集中做什麼 使用 Microsoft Entra ID 授權來取得 Kubernetes API
限制對特定自訂資源類型的存取 Entra ID 授權中的 ABAC 條件
以 Kubernetes 物件的形式，授權每個叢集、每個命名空間的權限。 使用 Kubernetes RBAC 搭配 Entra 整合
讓叢集從 ACR 提取或連接磁碟 AKS 中的管理身份
讓 pods 不需要憑證即可存取 金鑰保存庫 或 Storage。 Microsoft Entra 工作負載 ID概述
限制誰可以下載叢集 kubeconfig 限制對叢集設定檔的存取
建立一個具備預設身份態勢的生產環境叢集 建立 AKS 自動叢集

AKS 服務權限參考

關於 AKS 使用的 Azure 權限（建立叢集的身份、執行時的叢集身份、額外的叢集身份權限，以及 AKS 節點存取），請參見 AKS 服務權限參考。

相關內容

如需有關 Kubernetes 及 AKS 核心概念的詳細資訊，請參閱下列文章：

  • 上次更新時間：