在 Azure Kubernetes Service (AKS) 中對 Kubernetes API 使用 Microsoft Entra ID 授權

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

本文說明如何透過使用 Microsoft Entra ID 身份來授權 Azure Kubernetes Service (AKS) 中對 Kubernetes API 的呼叫。 Microsoft Entra ID 對 Kubernetes API 的授權使用 Azure RBAC 角色分配來授予 Kubernetes 資源的存取權限。 對於內建的 Kubernetes 資源,可以在叢集或命名空間範圍內指派 AKS 內建角色之一(例如 Azure Kubernetes Service RBAC Reader)。 對於自訂資源(CRD),請指派一個帶有 Azure ABAC 條件的自訂角色,指定受指派者可以存取哪些 CRD 群組或類型。 這兩個角色指派結合在一起:一個授予標準 Kubernetes 資源的存取權,另一個則提供對特定自訂資源的條件存取。

對大多數生產工作負載來說,AKS 自動是 AKS 的預設生產就緒預設。 AKS Automatic 叢集已預先設定 Azure RBAC 以進行 Kubernetes 授權,因此你可以專注於為使用者、群組和服務主體指派正確的 Microsoft Entra 角色。

關於 AKS 中可用 Kubernetes API 授權選項的概念概述,請參見 叢集授權概念。

備註

當你在 Microsoft Entra ID 與 AKS 之間使用整合驗證時,你可以將 Microsoft Entra 的使用者、群組或服務主體作為 Kubernetes 基於角色的存取控制(Kubernetes RBAC)中的主體。 透過使用 Microsoft Entra ID 授權,你不需要分別管理 Kubernetes 的使用者身份和憑證。 不過,你仍然需要分別設定和管理 Microsoft Entra ID 角色指派及任何 Kubernetes 的 RBAC 綁定。

備註

AKS Automatic 叢集已預先設定為使用 Azure RBAC 進行 Kubernetes 授權。 你不需要在 AKS Automatic 叢集上啟用 --enable-azure-rbac。 在 AKS Standard 中,你可以根據叢集設定啟用或停用 Azure RBAC。

Prerequisites

  • 你需要安裝並設定 Azure CLI 2.24.0 或更新版本。 執行 az --version 以尋找版本。 如果您需要安裝或升級,請參閱 安裝 Azure CLI。
  • 你需要 kubectl,最低版本是 1.18.3。
  • 你需要在叢集啟用管理式 Microsoft Entra 整合,才能為 Kubernetes API 新增 Microsoft Entra ID 授權。 如果你需要啟用管理式的 Microsoft Entra 整合,請參考 AKS 中使用 Microsoft Entra ID。
  • 新的角色指派最多可能需要五分鐘才能傳播,並由授權伺服器更新。
  • Kubernetes API 的 Microsoft Entra ID 授權要求,用於驗證的 Microsoft Entra 租用戶必須與包含 AKS 叢集之訂用帳戶的租用戶相同。

AKS 叢集模式運作方式

叢集模式 適用於 Kubernetes 授權的 Azure RBAC
AKS 自動化系统 預先設定(預設啟用)
AKS 標準 選用(使用 --enable-azure-rbac 啟用)

建立新的 AKS 叢集,並使用受控的 Microsoft Entra 整合和 Microsoft Entra ID 授權

針對新的生產工作負載,請使用 AKS Automatic。 AKS Automatic 叢集已預先設定適用於 Kubernetes 授權的 Azure RBAC。

  1. 依照 建立 Azure Kubernetes Service (AKS) Automatic 叢集 中的步驟建立 AKS Automatic 叢集。

  2. 可選:用指令az aks show確認你的叢集是否啟用了 Azure RBAC for Kubernetes 授權。

    # Set environment variables
    export RESOURCE_GROUP=<resource-group-name>
    export CLUSTER_NAME=<cluster-name>
    
    az aks show \
      --resource-group $RESOURCE_GROUP \
      --name $CLUSTER_NAME \
      --query "aadProfile.enableAzureRbac" \
      --output tsv
    

AKS 標準

  1. 使用 az group create 指令建立一個Azure資源群組。

    export RESOURCE_GROUP=<resource-group-name>
    export LOCATION=<azure-region>
    
    az group create --name $RESOURCE_GROUP --location $LOCATION
    
  2. 使用 az aks create 命令建立 AKS Standard 叢集,並使用受控的 Microsoft Entra 整合與 Microsoft Entra ID 授權。

    export CLUSTER_NAME=<cluster-name>
    
    az aks create \
        --resource-group $RESOURCE_GROUP \
        --name $CLUSTER_NAME \
        --enable-aad \
        --enable-azure-rbac \
        --generate-ssh-keys
    

    您的輸出看起來應類似下列的範例輸出:

    "AADProfile": {
        "adminGroupObjectIds": null,
        "clientAppId": null,
        "enableAzureRbac": true,
        "managed": true,
        "serverAppId": null,
        "serverAppSecret": null,
        "tenantId": "****-****-****-****-****"
    }
    

在現有 AKS 叢集啟用 Microsoft Entra ID 授權

對於現有的 AKS Standard 叢集,請使用 az aks update 命令搭配 --enable-azure-rbac 旗標,為 Kubernetes API 啟用 Microsoft Entra ID 授權。

# Set environment variables
export RESOURCE_GROUP=<resource-group-name>
export CLUSTER_NAME=<cluster-name>

# Enable Microsoft Entra ID authorization for the Kubernetes API
az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --enable-azure-rbac

AKS Automatic clusters 已經預先設定咗 Azure RBAC for Kubernetes 授權。 您不需要為 AKS Automatic 執行 --enable-azure-rbac。

AKS 內建角色

AKS 提供以下內建角色:

角色 Description
Azure Kubernetes Service RBAC 讀取者 允許唯讀存取來查看命名空間中的大部分物件。 其不允許檢視角色或角色繫結。 此角色不允許查看 Secrets,因為讀取 Secrets 內容可存取命名空間中的 ServiceAccount 憑證,允許以命名空間內任何 ServiceAccount 身份存取 API(一種權限升級)。
Azure Kubernetes Service RBAC 寫入者 允許命名空間中大部分物件的讀取/寫入存取權。 不允許檢視或修改角色或角色繫結。 然而,此角色允許以命名空間中任一 ServiceAccount 身份存取 Secrets 並執行 Pods,因此可用來取得該命名空間中任一 ServiceAccount 的 API 存取層級。
Azure Kubernetes Service RBAC 管理員 允許管理員存取權,其用途是在命名空間內授與。 允許命名空間 (或叢集範圍) 中大部分的資源的讀取/寫入存取權 ,包括可在命名空間內建立角色和角色繫結。 此角色不允許對資源配額或命名空間本身進行寫入存取。
Azure Kubernetes Service RBAC Cluster Admin 允許進階使用者在任何資源上執行的存取權。。 它能完全控制叢集中的所有資源及所有命名空間。

建立叢集存取的角色指派

  1. 用指令 az aks show 取得你的 AKS 資源 ID。

    # Set environment variables
    export RESOURCE_GROUP=<resource-group-name>
    export CLUSTER_NAME=<cluster-name>
    
    # Get the AKS resource ID
    AKS_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query id --output tsv)
    
  2. 使用命令 az role assignment create 建立角色指派。 <AAD-ENTITY-ID> 可以是使用者名稱或服務主體的客戶端 ID。 以下範例為 Azure Kubernetes Service RBAC 管理員角色建立角色指派。

    # Set environment variables
    export RESOURCE_GROUP=<resource-group-name>
    export CLUSTER_NAME=<cluster-name>
    
    # Get the AKS resource ID
    AKS_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query id --output tsv)
    
    # Create a role assignment for the Azure Kubernetes Service RBAC Admin role
    az role assignment create --role "Azure Kubernetes Service RBAC Admin" --assignee <AAD-ENTITY-ID> --scope $AKS_ID
    

    備註

    你可以使用 az role assignment create 命令,將範圍設定為叢集內特定的命名空間,以建立 Azure Kubernetes Service RBAC Reader 和 Azure Kubernetes Service RBAC Writer 角色指派。

    az role assignment create --role "Azure Kubernetes Service RBAC Reader" --assignee <AAD-ENTITY-ID> --scope $AKS_ID/namespaces/<namespace-name>
    

建立自訂角色定義

針對內建的 Kubernetes 資源,自訂角色定義會參考Microsoft.ContainerService/managedClusters/底下的對應 API 群組動作。 以下範例允許使用者只讀取部署資料,無法讀取其他資料。 完整可能的操作清單,請參見 Microsoft.ContainerService 作業。

對於自訂資源,自訂角色必須授予適用的自訂資源資料動作,例如 Microsoft.ContainerService/managedClusters/customresources/read。 僅靠自訂角色並不能依照自訂資源定義(CRD)群組或類型來過濾存取。 要套用這個篩選,可以在角色指派中加入 Azure ABAC 條件。 完整程序請參閱使用 ABAC 條件限制自訂資源存取。

  1. 要建立自訂角色定義,請複製以下檔案,替換 <YOUR-SUBSCRIPTION-ID> 成你自己的訂閱 ID,然後儲存為 deploy-view.json。

    {
        "Name": "AKS Deployment Reader",
        "Description": "Lets you view all deployments in cluster/namespace.",
        "Actions": [],
        "NotActions": [],
        "DataActions": [
            "Microsoft.ContainerService/managedClusters/apps/deployments/read"
        ],
        "NotDataActions": [],
        "assignableScopes": [
            "/subscriptions/<YOUR-SUBSCRIPTION-ID>"
        ]
    }
    
  2. 用 az role definition create 指令建立角色定義,並將 --role-definition 設為 deploy-view.json,這是你在前一步驟建立的檔案。

    az role definition create --role-definition @deploy-view.json 
    
  3. 使用指令 az role assignment create 將角色定義指派給使用者或其他身份。

        # Set environment variables
    export RESOURCE_GROUP=<resource-group-name>
    export CLUSTER_NAME=<cluster-name>
    
    # Get the AKS resource ID
    AKS_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query id --output tsv)
    
    # Create a role assignment for the AKS Deployment Reader role
    az role assignment create --role "AKS Deployment Reader" --assignee <AAD-ENTITY-ID> --scope $AKS_ID
    

使用 ABAC 條件限制自訂資源存取(預覽)

Important

AKS 預覽功能可透過自願加入的方式使用。 預覽是「依現況」及「可用時」提供的,並不包括在服務等級協定和有限保固之內。 客戶支援部門會盡最大努力,部分支援 AKS 預覽。 因此,這些功能不適合實際執行用途。 如需詳細資訊,請參閱下列支援文章:

ABAC 條件允許你將 Microsoft Entra ID 角色指派篩選到特定的自訂資源(CRD)群組和類型——集中從 Microsoft Entra ID 進行,無需撰寫每個叢集的 Kubernetes RBAC Role 和RoleBinding清單。 如需 Azure ABAC 的背景資訊,請參閱 什麼是 Azure 角色指派條件?

何時使用 ABAC 條件

當你想要使用此功能時:

  • 限制受讓人可以列出或取得的CRD群組或類型。
  • 集中強制執行來自 Microsoft Entra ID 的自訂資源存取邊界,無需管理每個叢集上的 Kubernetes RBAC Role 和 RoleBinding 物件。
  • 區分由不同運算子發布的CRD(例如,允許secrets-store.csi.x-k8s.io,但阻止security.istio.io)。

可用的條件屬性

在 AKS 叢集上為 Kubernetes API 撰寫條件時,可用以下請求屬性:

Attribute Description
Microsoft.ContainerService/managedClusters/customResources:group 被存取的自訂資源的 API 群組(例如 secrets-store.csi.x-k8s.io)。
Microsoft.ContainerService/managedClusters/customResources:kind 所存取的自訂資源類型(例如, secretproviderclasses)。

在角色分配中加入ABAC條件

以下範例建立一個 AKS CRD Reader 自訂角色,授予對自訂資源的讀取權限。 然後,它會使用條件指派該角色,僅允許存取 secretproviderclasses 資源,其位於 secrets-store.csi.x-k8s.io 群組中 (這是 Azure Key Vault 提供者用於 Secrets Store CSI Driver 的 CRD)。

  1. 將以下角色定義儲存到一個名為 crd-reader.json的檔案,並替換 <YOUR-SUBSCRIPTION-ID> 成你自己的訂閱 ID。

    {
        "Name": "AKS CRD Reader",
        "Description": "Lets you read custom resources in the cluster.",
        "Actions": [],
        "NotActions": [],
        "DataActions": [
            "Microsoft.ContainerService/managedClusters/customresources/read"
        ],
        "NotDataActions": [],
        "assignableScopes": [
            "/subscriptions/<YOUR-SUBSCRIPTION-ID>"
        ]
    }
    
  2. 用指令 az role definition create 建立角色定義。

    az role definition create --role-definition @crd-reader.json
    
  3. 將以下條件儲存到一個名為 abac-condition.txt的檔案中。 此條件允許非自訂資源讀取不更改地通過,並限制自訂資源讀取只能在特定群組和類型中進行。

    (
     (
      !(ActionMatches{'Microsoft.ContainerService/managedClusters/customresources/read'})
     )
     OR
     (
      @Request[Microsoft.ContainerService/managedClusters/customResources:group] StringEqualsIgnoreCase 'secrets-store.csi.x-k8s.io'
      AND
      @Request[Microsoft.ContainerService/managedClusters/customResources:kind] StringEqualsIgnoreCase 'secretproviderclasses'
     )
    )
    
  4. 使用 az role assignment create 指令建立帶有條件的角色指派。

    # Set environment variables
    export RESOURCE_GROUP=<resource-group-name>
    export CLUSTER_NAME=<cluster-name>
    
    # Get the AKS resource ID
    AKS_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query id --output tsv)
    
    # Create a role assignment for the AKS CRD Reader role with an ABAC condition
    az role assignment create \
        --role "AKS CRD Reader" \
        --assignee <AAD-ENTITY-ID> \
        --scope $AKS_ID \
        --condition "$(cat abac-condition.txt)" \
        --condition-version "2.0" \
        --description "Allow reads on SecretProviderClass resources only"
    

你也可以透過 Azure 入口網站新增條件。 在 「新增角色指派 」頁面,選擇 「條件 」標籤,然後選擇 「新增條件 」,並使用視覺編輯器建立表達式。

確認狀況

在角色指派傳播完成後 (最多 5 分鐘),請以受指派者的身分登入,並確認可讀取被允許的 CRD,但無法讀取其他的 CRD。

  1. 用指令 az aks get-credentials 取得叢集憑證。

    # Set environment variables
    export RESOURCE_GROUP=<resource-group-name>
    export CLUSTER_NAME=<cluster-name>
    
    # Get the cluster credentials
    az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME
    
  2. 列出secretproviderclasses來自條件允許的secrets-store.csi.x-k8s.io群組。 指令應該會成功,並回傳現有資源或空清單(或如果叢集上沒有安裝 CRD,則會顯示未找到錯誤)。

    kubectl get secretproviderclasses.secrets-store.csi.x-k8s.io --all-namespaces
    
  3. 列出authorizationpolicies來自條件封鎖的security.istio.io群組。 該命令應會因 Microsoft Entra ID 授權 Webhook 傳回的 Forbidden 錯誤而失敗 (假設 Istio CRD 已安裝在叢集中;否則 kubectl 會在 API 伺服器到達授權 Webhook 之前傳回找不到錯誤)。

    kubectl get authorizationpolicies.security.istio.io --all-namespaces
    

清理資源

停用 Microsoft Entra ID 授權

使用帶有az aks update旗標的--disable-azure-rbac指令移除 Microsoft Entra ID 授權。

# Set environment variables
export RESOURCE_GROUP=<resource-group-name>
export CLUSTER_NAME=<cluster-name>

# Disable Microsoft Entra ID authorization for the Kubernetes API
az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --disable-azure-rbac

刪除角色指派

  1. 使用指令 az role assignment list 列出角色分配。

    # Set environment variables
    export RESOURCE_GROUP=<resource-group-name>
    export CLUSTER_NAME=<cluster-name>
    
    # Get the AKS resource ID
    AKS_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query id --output tsv)
    
    # List role assignments for the AKS cluster
    az role assignment list --scope $AKS_ID --query [].id --output tsv
    
  2. 使用 az role assignment delete 指令刪除角色分配。

    az role assignment delete --ids <LIST OF ASSIGNMENT IDS>
    

刪除角色定義

用指令 az role definition delete 刪除自訂角色定義。

az role definition delete --name "AKS Deployment Reader"

刪除資源群組與 AKS 叢集

用指令 az group delete 刪除資源群組(以及其中包含的 AKS 叢集)。

# Set environment variables
export RESOURCE_GROUP=<resource-group-name>

# Delete the resource group and all resources in it
az group delete --name $RESOURCE_GROUP --yes --no-wait

欲了解更多AKS,請參閱以下文章: