上一個

下一個

設定 Azure Kubernetes Service 的驗證

已完成

當您在 Azure Kubernetes Service (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 將角色繫結至使用者或群組。

下圖顯示 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 和原則的先前驗證成功。

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

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

在 Kubernetes 中，您會提供叢集資源的細微存取控制。 您可以在叢集層級或特定命名空間定義權限。 您可以決定可以管理哪些資源，以及哪些權限。 然後，您可以使用繫結將這些角色套用至使用者或群組。

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

使用 Azure RBAC

最佳做法指南：使用 Azure RBAC 來定義一或多個訂用帳戶中 AKS 資源的最低必要使用者和群組權限。

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

• 存取 Azure 訂用帳戶上的 AKS 資源。
• 此存取層級可讓您:
  • 使用 AKS API 控制調整或升級叢集
  • 提取您的 kubeconfig。
• 存取 Kubernetes API。
• 此存取層級由下列任一項控制:
  • Kubernetes RBAC (傳統上) 或
  • 藉由整合 Azure RBAC 與 AKS 以進行 kubernetes 授權。

利用 Pod 受控身分識別

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

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

使用 Azure 資源的 Pod 受控身分識別 (預覽版)，您可以透過 Microsoft Entra ID 自動請求存取服務。 Pod 受控識別目前為 AKS 預覽狀態。

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。 身分識別須由使用者手動指派和管理。 在此模式中，當您使用 az aks pod-identity add 命令將 Pod 身分識別新增至 Azure Kubernetes Service (AKS) 叢集時，會在 --namespace 參數所指定的命名空間中建立 AzureIdentity 和 AzureIdentityBinding，而 AKS 資源提供者會將 --identity-resource-id 參數所指定的受控識別指派給 AKS 叢集中每個節點集區的虛擬機器擴展集。
  

注意

如果您改為決定使用 AKS 叢集附加元件安裝 Microsoft Entra Pod 受控識別，安裝程式會使用受控模式。

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) 伺服器是 Pod，會在 AKS 叢集中的每個節點上以 DaemonSet 的形式執行。 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

繼續