Azure Kubernetes Service (AKS) 中驗證和授權的最佳做法

當您在 Azure Kubernetes Service (AKS) 中部署和維護叢集時，您會實作管理資源與服務的存取方式。 如果沒有這些控制項:

• 帳戶可以存取不必要的資源和服務。
• 追蹤用來進行變更的認證可能很困難。

在本文，我們討論叢集操作員可遵循哪些建議的做法來管理 AKS 叢集的存取與識別。 您將了解如何：

使用 Microsoft Entra ID

最佳做法指導方針

使用 Microsoft Entra 整合部署 AKS 叢集。 使用 Microsoft Entra ID 會將身分識別管理層集中化。 使用者帳戶或群組狀態的任何變更都會在存取 AKS 叢集時自動更新。 使用 Roles、ClusterRoles 或 Bindings，將使用者或群組範圍界定為最低權限數目。

您的 Kubernetes 叢集開發人員和應用程式擁有者需要存取不同的資源。 Kubernetes 缺少身分識別管理解決方案，可讓您控制使用者可以與其互動的資源。 相反地，您可以將叢集與現有的身分識別解決方案整合，例如 Microsoft Entra ID，這是企業就緒的身分識別管理解決方案。

透過 AKS 中的 Microsoft Entra 整合叢集，您可建立用於定義資源存取權限的角色或 ClusterRoles。 接著，您可以從 Microsoft Entra ID 將角色繫結至使用者或群組。 在下一節中深入了解 Kubernetes RBAC。 下圖顯示 Microsoft Entra 整合以及如何控制資源存取權：

1. 開發人員會使用 Microsoft Entra ID 進行驗證。
2. Microsoft Entra 權杖發行端點會發出存取權杖。
3. 開發人員使用 Microsoft Entra 權杖 (如 kubectl create pod) 執行動作。
4. Kubernetes 會使用 Microsoft Entra ID 驗證權杖，並擷取開發人員的群組成員資格。
5. 已套用 Kubernetes RBAC 和叢集原則。
6. 根據先前對 Microsoft Entra 群組成員資格及 Kubernetes RBAC 與原則的驗證，開發人員的請求為成功。

若要建立使用 Microsoft Entra ID 的 AKS 叢集，請參閱整合 Microsoft Entra ID 與 AKS。

使用 Kubernetes 角色型存取控制 (Kubernetes RBAC)

最佳做法指導方針

使用 Kubernetes RBAC 來定義叢集資源的使用者或群組權限。 建立指派最少所需權限的角色和繫結。 與 Microsoft Entra ID 整合，以自動更新任何使用者狀態或群組成員資格變更，並保留叢集資源的存取權。

在 Kubernetes 中，您會提供叢集資源的細微存取控制。 您可以在叢集層級或特定命名空間定義權限。 您可以決定可以管理哪些資源，以及哪些權限。 然後，您可以使用繫結將這些角色套用至使用者或群組。 如需角色、ClusterRoles 和繫結的詳細資訊，請參閱 Azure Kubernetes Service (AKS) 的存取和身分識別選項。

例如，您建立具有完整存取權限的角色，名為 finance-app 的命名空間資源，如下面範例 YAML 資訊清單所示：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role
  namespace: finance-app
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

然後建立 RoleBinding，並將 Microsoft Entra 使用者developer1@contoso.com綁定到該它，如下面 YAML 資訊清單所示：

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role-binding
  namespace: finance-app
subjects:
- kind: User
  name: developer1@contoso.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: finance-app-full-access-role
  apiGroup: rbac.authorization.k8s.io

developer1@contoso.com 在通過對 AKS 叢集的驗證後，他對於 finance-app 命名空間中的資源即具有完整權限。 如此一來，您會以邏輯方式分隔和控制資源的存取權。 搭配 Microsoft Entra ID 整合使用 Kubernetes RBAC。

若要瞭解如何使用 Microsoft Entra 群組透過 Kube RBAC 控制對 Kube 資源的存取，請參閱在 AKS 使用角色型存取控制及 Microsoft Entra 身分識別控制叢集資源的存取。

使用 Azure RBAC

最佳做法指導方針

使用 Azure RBAC 定義一或多個訂用帳戶中使用者或群組所具的 AKS 資源最低必要權限。

完全操作 AKS 叢集需要兩個層級的存取:

• 存取 Azure 訂用帳戶上的 AKS 資源。

  此存取層級可讓您：

  • 使用 AKS API 控制調整或升級叢集
  • 提取您的 kubeconfig。

  若要瞭解如何控制對 AKS 資源及kubeconfig的存取，請參閱限制對叢集設定檔的存取。

• 存取 Kubernetes API。

  此存取層級由下列其中一項作業控制：

  • Kubernetes RBAC (傳統) 或
  • 藉由整合 Azure RBAC 與 AKS 以進行 kubernetes 授權。

  若要瞭解如何使用 Azure RBAC 將權限精確地給予 Kubernetes API，請參閱使用 Azure RBAC 進行 Kubernetes 授權。

利用 Pod 受控身分識別

請勿使用 Pod 或容器映像內的固定認證，因為這些認證有外洩或濫用的風險。 請改用 Pod 身分識別來使用 Microsoft Entra ID 自動請求存取權。

若要存取其他 Azure 資源，例如 Azure Cosmos DB、Key Vault 或 Blob 儲存體，Pod 需要驗證憑證。 您可以使用容器映像來定義驗證憑證或將其作為 Kubernetes 機密植入。 兩種方式皆須手動建立並指派。 認證通常會跨 Pod 重複使用，而不會定期輪替。

使用 Azure 資源的 Pod 受控身分識別 (預覽版)，您可以透過 Microsoft Entra ID 自動請求存取服務。 Pod 受控身分識別目前正在 AKS 預覽。 請參閱在 Azure Kubernetes Services 中使用 Microsoft Entra Pod 受控身分識別 (預覽版) 文件以開始使用。

Microsoft Entra Pod 受控識別 (預覽版) 支援兩種作業模式：

• 標準模式：在這個模式，下面 2 個元件會部署至 AKS 叢集：

  • 受控識別控制器 (MIC) ：此Kubernetes 控制器可透過 Kubernetes API 伺服器監看 Pod、AzureIdentity 和 AzureIdentityBinding 的變更。 當其偵測到相關的變更時，MIC 會視需要新增或刪除 AzureAssignedIdentity。 具體而言，當 Pod 進行排程時，MIC 會將 Azure 上的受控識別指派給節點集區在建立階段期間所使用的基礎虛擬機器擴展集。 刪除所有使用身分識別的 Pod 時，其會從節點集區的虛擬機器擴展集移除身分識別，除非其他 Pod 使用相同的受控識別。 建立或刪除 AzureIdentity 或 AzureIdentityBinding 時，MIC 會採取類似的動作。

  • 節點管理身分識別 (NMI)：此 Pod 在 AKS 叢集各節點以 DaemonSet 形式執行。 NMI 會攔截每個節點上的 Azure Instance Metadata Service 的安全性權杖請求。 這會將請求重新導至自身，並驗證 Pod 是否具有請求權杖之識別存取權，並代表應用程式從 Microsoft Entra 租用戶擷取權杖。

• 受控模式：在這個模式，僅有 NMI。 身分識別須由使用者手動指派和管理。 如需詳細資訊，請參閱受控模式中的 Pod 身分識別。 在這個模式，當使用 az aks pod-identity add 命令將 Pod 識別加入 Azure Kubernetes Service (AKS) 叢集時，它會在--namespace參數指定的命名空間中建立 AzureIdentity 及 AzureIdentityBinding，而 AKS 資源提供者則會將--identity-resource-id參數指定的受控身分標識分配給 AKS 叢集中每個節點集區的虛擬機器擴充集。

managed 模式提供 standard 的下列優點：

• 節點集區的虛擬機器擴充集的身分指派可能需要 40 到 60 秒。 如果 cronjob 或應用程式需要存取識別碼，且無法忍受指派延遲，最好使用 managed 模式，因為識別碼已預先指派給節點集區的虛擬機器擴充集區。 可手動或使用 az aks pod-identity add 指令。
• 在 standard 模式，MIC 需要對 AKS 叢集使用的虛擬機器擴充集具有寫入權限，以及 Managed Identity Operator 對使用者指派的受控識別具有寫入權限。 在 managed mode 執行時，由於不是 MIC，因此無須指派角色。

Pod 受控身分識別無需手動為 Pod 定義憑證，而是即時請求存取權杖，僅使用該權杖存取其分配的資源。 在 AKS 中，有兩個元件用於處理允許 Pod 使用受控識別的作業：

• 節點管理身分識別 (NMI) 伺服器是在 AKS 叢集中的每個節點上以 DaemonSet 形式執行的 Pod。 NMI 伺服器會接聽 Pod 對 Azure 服務的要求。
• Azure 資源提供者會查詢 Kubernetes API 伺服器，並檢查對應至 Pod 的 Azure 身分識別對應。

Pod 從 Microsoft Entra ID 請求安全性權杖以存取 Azure 資源時，網路規則會將流量重新導向 NMI 伺服器。

1. NMI 伺服器：

   • 根據其遠端位址，識別要求存取 Azure 資源的 Pod。
   • 查詢 Azure 資源提供者。

2. Azure 資源提供者會檢查 AKS 叢集中的 Azure 身分識別對應。

3. NMI 伺服器會根據 Pod 的身分識別對應來要求 Microsoft Entra ID 的存取權杖。

4. Microsoft Entra ID 會將存取權提供給 NMI 伺服器，繼而傳回給 Pod。

   • Pod 可以使用此存取權杖請求存取 Azure 中的資源。

在下列範例中，開發人員會建立 Pod，並使用受控識別要求存取 Azure SQL Database：

1. 叢集操作員會建立服務帳戶，以利在 Pod 請求存取資源時對應身分識別。
2. 已部署 NMI 伺服器 (以轉送 Pod 要求) 及 Azure 資源提供者 (以取得 Microsoft Entra ID 的存取權杖)。
3. 開發人員使用受控識別部署了透過 NMI 伺服器要求存取權杖的 Pod。
4. 該權杖會傳回 Pod，並用於存取 Azure SQL Database

若要使用 Pod 受控身分識，請參閱在 Azure Kubernetes Service 中使用 Microsoft Entra Pod 受控身分識 (預覽版)。

下一步

這篇最佳做法文章主要討論叢集和資源的驗證和授權。 若要實作這些最佳做法，請參閱下列文章：

• 整合 Microsoft Entra ID 與 AKS
• 在 Azure Kubernetes Service (AKS) 中使用 Microsoft Entra Pod 受控識別 (預覽版)

如需 AKS 中叢集作業的相關詳細資訊，請參閱下列最佳作法：

• 多租用戶和叢集隔離
• 基本的 Kube 排程器功能
• Kube 排程器的進階功能