Używanie autoryzacji Microsoft Entra ID dla interfejsu API Kubernetes w Azure Kubernetes Service (AKS)

Dotyczy: ✔️ AKS Automatic AKS Standard ✔️

W tym artykule pokazano, jak autoryzować wywołania interfejsu API Kubernetes w usłudze Azure Kubernetes Service (AKS) przy użyciu tożsamości Microsoft Entra ID. Autoryzacja Microsoft Entra ID dla interfejsu API platformy Kubernetes używa przypisań ról Azure RBAC do przyznawania dostępu do zasobów Kubernetes. W przypadku wbudowanych zasobów Kubernetes przypisz jedną z wbudowanych ról AKS (taką jak Azure Kubernetes Service RBAC Reader) na poziomie klastra lub przestrzeni nazw. W przypadku zasobów niestandardowych (CRD), przypisz rolę niestandardową z warunkami usługi Azure ABAC, w których określono, do których grup CRD lub typów może uzyskać dostęp osoba przypisana. Dwa przypisania ról stanowią: jedno zapewnia dostęp do standardowych zasobów Kubernetes, a drugie zapewnia warunkowy dostęp do określonych zasobów niestandardowych.

W przypadku większości obciążeń produkcyjnych AKS Automatic to zalecany, gotowy do użycia produkcyjnego domyślny wybór dla usługi AKS. Klastry automatyczne AKS są wstępnie skonfigurowane z usługą Azure RBAC na potrzeby autoryzacji w Kubernetes, dzięki czemu można skupić się na przypisywaniu odpowiednich ról Microsoft Entra użytkownikom, grupom i nazwom głównym usług.

Aby zapoznać się z koncepcyjnym omówieniem dostępnych opcji autoryzacji interfejsu API platformy Kubernetes w usłudze AKS, zobacz Pojęcia dotyczące autoryzacji klastra.

Note

Jeśli używasz zintegrowanego uwierzytelniania między identyfikatorem Entra firmy Microsoft i usługą AKS, możesz użyć użytkowników, grup lub jednostek usługi firmy Microsoft jako podmiotów w kontroli dostępu opartej na rolach (Kubernetes RBAC) platformy Kubernetes. Korzystając z autoryzacji Microsoft Entra ID, nie musisz oddzielnie zarządzać tożsamościami użytkowników i poświadczeniami dla platformy Kubernetes. Jednak nadal musisz osobno skonfigurować przypisania ról w usłudze Microsoft Entra ID oraz wszelkie powiązania RBAC w Kubernetes i nimi zarządzać.

Note

Klastry automatyczne usługi AKS są wstępnie skonfigurowane do używania Azure kontroli dostępu opartej na rolach na potrzeby autoryzacji platformy Kubernetes. Nie musisz włączać --enable-azure-rbac w klastrach AKS Automatic. W usłudze AKS Standard można włączyć lub wyłączyć Azure kontroli dostępu opartej na rolach na podstawie konfiguracji klastra.

Prerequisites

  • Potrzebny jest interfejs wiersza polecenia platformy Azure w wersji 2.24.0 lub nowszej zainstalowany i skonfigurowany. Uruchom az --version, aby znaleźć wersję. Jeśli musisz zainstalować lub uaktualnić, zobacz Install Azure CLI.
  • Potrzebujesz kubectl, w wersji co najmniej 1.18.3.
  • Aby dodać autoryzację Microsoft Entra ID dla interfejsu API Kubernetes, potrzebna jest integracja Microsoft Entra zarządzana w klastrze. Jeśli musisz włączyć zarządzaną integrację z usługą Microsoft Entra, zobacz Korzystanie z identyfikatora Microsoft Entra w usłudze AKS.
  • Propagowanie nowych przydziałów ról może zająć do pięciu minut, zanim zostaną zaktualizowane przez serwer autoryzacji.
  • Autoryzacja interfejsu API platformy Kubernetes za pomocą Microsoft Entra ID wymaga, aby dzierżawa Microsoft Entra skonfigurowana do uwierzytelniania była taka sama jak dzierżawa subskrypcji, do której należy klaster AKS.

Zachowanie trybu klastra AKS

Tryb klastra RBAC Azure dla autoryzacji w Kubernetes
Automatyczne usługi AKS Wstępnie skonfigurowane (domyślnie włączone)
AKS Standard Opcjonalne (włącz za pomocą --enable-azure-rbac)

Utwórz nowy klaster AKS z zarządzaną integracją z platformą Microsoft Entra i autoryzacją Microsoft Entra ID

W przypadku nowych obciążeń produkcyjnych należy użyć usługi AKS Automatic. Mechanizm kontroli dostępu opartej na rolach (RBAC) platformy Azure na potrzeby autoryzacji w Kubernetes jest prekonfigurowany w klastrach AKS Automatic.

  1. Utwórz klaster automatyczny usługi AKS, postępując zgodnie z instrukcjami Tworzenie klastra automatycznego Azure Kubernetes Service (AKS).

  2. Opcjonalnie: sprawdź za pomocą polecenia az aks show, czy w klastrze jest włączona kontrola dostępu oparta na rolach platformy Azure (Azure RBAC) na potrzeby autoryzacji 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 Standard

  1. Utwórz grupę zasobów Azure przy użyciu polecenia az group create.

    export RESOURCE_GROUP=<resource-group-name>
    export LOCATION=<azure-region>
    
    az group create --name $RESOURCE_GROUP --location $LOCATION
    
  2. Utwórz klaster AKS w warstwie Standard z zarządzaną integracją z Microsoft Entra i autoryzacją Microsoft Entra ID przy użyciu polecenia az aks create.

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

    Dane wyjściowe powinny wyglądać podobnie do następujących przykładowych danych wyjściowych:

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

Włącz autoryzację Microsoft Entra ID w istniejącym klastrze AKS

W przypadku istniejących klastrów AKS w warstwie Standard włącz autoryzację Microsoft Entra ID dla interfejsu API platformy Kubernetes za pomocą polecenia az aks update z flagą --enable-azure-rbac.

# 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

Klastry automatyczne AKS mają już wstępnie skonfigurowany mechanizm Azure RBAC na potrzeby autoryzacji w Kubernetes. Nie musisz uruchamiać --enable-azure-rbac dla funkcji AKS Automatic.

Wbudowane role usługi AKS

AKS udostępnia następujące wbudowane role:

roli Description
Czytelnik RBAC w usłudze Azure Kubernetes Service Umożliwia dostęp tylko do odczytu, aby wyświetlić większość obiektów w przestrzeni nazw. Nie zezwala na wyświetlanie ról ani powiązań ról. Ta rola nie zezwala na wyświetlanie Secrets, ponieważ odczytywanie zawartości tajemnic umożliwia dostęp do poświadczeń usługi ServiceAccount w przestrzeni nazw, co umożliwia dostęp do interfejsu API jako dowolne konto usługi w tej przestrzeni nazw (forma podniesienia uprawnień).
Autor RBAC usługi Azure Kubernetes Service Umożliwia dostęp do odczytu/zapisu do większości obiektów w przestrzeni nazw. Ta rola nie zezwala na wyświetlanie ani modyfikowanie ról ani powiązań ról. Jednak ta rola umożliwia dostęp do Secrets i uruchamianie podów jako dowolne KontoUsługi w przestrzeni nazw, co pozwala na uzyskanie poziomów dostępu do interfejsu API dowolnego KontoUsługi w przestrzeni nazw.
Administrator RBAC w usłudze Azure Kubernetes Service Zezwala na dostęp administracyjny, który powinien być udzielany w ramach przestrzeni nazw. Umożliwia dostęp do odczytu/zapisu do większości zasobów w przestrzeni nazw (lub zakresie klastra), w tym możliwość tworzenia ról i powiązań ról w przestrzeni nazw. Ta rola nie zezwala na prawo zapisu do limitu przydziału zasobów ani do samej przestrzeni nazw.
Administrator klastrów RBAC usługi Azure Kubernetes Umożliwia dostęp administratora do wykonywania dowolnej akcji na dowolnym zasobie. Zapewnia pełną kontrolę nad każdym zasobem w klastrze i we wszystkich przestrzeniach nazw.

Tworzenie przypisań ról na potrzeby dostępu do klastra

  1. Pobierz identyfikator zasobu usługi AKS przy użyciu az aks show polecenia .

    # 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. Utwórz przypisanie roli używając polecenia az role assignment create. <AAD-ENTITY-ID> może być nazwą użytkownika lub identyfikatorem klienta jednostki usługi. W poniższym przykładzie utworzono przypisanie roli dla roli administratora RBAC Azure Kubernetes Service.

    # 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
    

    Note

    Można utworzyć przypisania ról Azure Kubernetes Service RBAC Reader i Azure Kubernetes Service RBAC Writer w zakresie określonej przestrzeni nazw w klastrze za pomocą polecenia az role assignment create, ustawiając zakres na żądaną przestrzeń nazw.

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

Tworzenie definicji ról niestandardowych

W przypadku wbudowanych zasobów Kubernetes niestandardowe definicje ról odwołują się do odpowiedniej akcji grupy API pod Microsoft.ContainerService/managedClusters/. Poniższy przykład umożliwia użytkownikowi tylko odczytywanie wdrożeń i nic innego. Aby uzyskać pełną listę możliwych akcji, zobacz Operacje Microsoft.ContainerService.

W przypadku zasobów niestandardowych rola niestandardowa musi przyznawać odpowiednie uprawnienie do operacji na danych dla zasobu niestandardowego, takie jak Microsoft.ContainerService/managedClusters/customresources/read. Sama rola niestandardowa nie filtruje dostępu według grupy lub rodzaju definicji zasobów niestandardowych (CRD). Aby zastosować takie filtrowanie, dodaj warunek ABAC platformy Azure do przypisania roli. Aby uzyskać pełną procedurę, zobacz Ograniczanie dostępu do zasobów niestandardowych przy użyciu warunków ABAC.

  1. Aby utworzyć własne definicje ról niestandardowych, skopiuj następujący plik, zastąp <YOUR-SUBSCRIPTION-ID> ciąg własnym identyfikatorem subskrypcji, a następnie zapisz go jako 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. Utwórz definicję roli za pomocą polecenia az role definition create, ustawiając --role-definition na plik deploy-view.json, który utworzyłeś w poprzednim kroku.

    az role definition create --role-definition @deploy-view.json 
    
  3. Przypisz definicję roli do użytkownika lub innej tożsamości przy użyciu az role assignment create polecenia .

        # 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
    

Ograniczanie dostępu do zasobów niestandardowych przy użyciu warunków ABAC (wersja zapoznawcza)

Ważna

Funkcje usługi AKS w wersji zapoznawczej są dostępne na zasadzie samoobsługi i wymagają zapisania się. Wersje zapoznawcze są udostępniane w wersji "as is" i "jako dostępne" i są wykluczone z umów dotyczących poziomu usług i ograniczonej gwarancji. Wersje zapoznawcze usługi AKS są częściowo objęte pomocą techniczną dla klientów, świadczoną w miarę możliwości. W związku z tym te funkcje nie są przeznaczone do użytku produkcyjnego. Aby uzyskać więcej informacji, zobacz następujące artykuły pomocy technicznej:

Warunki ABAC umożliwiają filtrowanie przypisań ról Microsoft Entra ID do określonych grup i typów niestandardowych zasobów (CRD) — centralnie, z poziomu Microsoft Entra ID, bez konieczności pisania manifestów Kubernetes RBAC Role i RoleBinding dla każdego klastra. Aby zapoznać się z Azure ABAC, zobacz Co to są Azure warunki przypisania roli?

Kiedy należy używać warunków ABAC

Użyj tej funkcji, jeśli chcesz:

  • Ogranicz, które grupy lub rodzaje CRD przypisany pracownik może wyświetlać lub pobierać.
  • Centralnie wymuszaj niestandardowe granice dostępu do zasobów z Microsoft Entra ID bez zarządzania Kubernetes RBAC Role i RoleBinding obiektami w każdym klastrze.
  • Rozróżnianie identyfikatorów CRD publikowanych przez różnych operatorów (na przykład zezwalaj na secrets-store.csi.x-k8s.io, blokując security.istio.io).

Dostępne atrybuty warunku

Następujące atrybuty żądania są dostępne podczas tworzenia warunków interfejsu API Kubernetes w klastrze usługi AKS:

Atrybut Description
Microsoft.ContainerService/managedClusters/customResources:group Grupa interfejsów API zasobu niestandardowego, do których uzyskuje się dostęp (na przykład secrets-store.csi.x-k8s.io).
Microsoft.ContainerService/managedClusters/customResources:kind Rodzaj zasobu niestandardowego, do którego uzyskiwany jest dostęp (na przykład secretproviderclasses).

Dodaj warunek ABAC do przypisania roli

Poniższy przykład tworzy niestandardową rolę AKS CRD Reader, która przyznaje dostęp do odczytu zasobów niestandardowych. Następnie przypisuje rolę z warunkiem, który zezwala tylko na dostęp do secretproviderclasses w grupie secrets-store.csi.x-k8s.io (czyli CRD używanego przez dostawcę Azure Key Vault dla Secrets Store CSI Driver).

  1. Zapisz następującą definicję roli w pliku o nazwie crd-reader.json, zastępując <YOUR-SUBSCRIPTION-ID> własnym identyfikatorem subskrypcji.

    {
        "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. Utwórz definicję roli przy użyciu az role definition create polecenia .

    az role definition create --role-definition @crd-reader.json
    
  3. Zapisz następujący warunek w pliku o nazwie abac-condition.txt. Warunek umożliwia odczyty zasobów innych niż niestandardowe bez zmian i ogranicza odczyty zasobów niestandardowych do określonej grupy i rodzaju.

    (
     (
      !(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. Utwórz przypisanie roli z wykorzystaniem warunku przy użyciu polecenia 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"
    

Warunek można również dodać za pośrednictwem witryny Azure Portal. Na stronie Dodawanie przypisania roli wybierz kartę Warunki , a następnie wybierz pozycję Dodaj warunek i użyj edytora wizualizacji, aby skompilować wyrażenie.

Weryfikowanie warunku

Po propagacji przypisania roli (do pięciu minut) zaloguj się jako osoba przypisana i upewnij się, że może odczytać dozwolony identyfikator CRD, ale nie inne identyfikatory CRD.

  1. Pobierz poświadczenia klastra przy użyciu polecenia 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. Lista secretproviderclasses z grupy secrets-store.csi.x-k8s.io, na którą warunek zezwala. Polecenie powinno zakończyć się powodzeniem i zwrócić istniejące zasoby lub pustą listę (lub błąd niewynalezienia, jeśli crD nie jest zainstalowany w klastrze).

    kubectl get secretproviderclasses.secrets-store.csi.x-k8s.io --all-namespaces
    
  3. Lista authorizationpolicies z grupy Istio security.istio.io, która blokuje działanie warunku. Polecenie powinno zakończyć się niepowodzeniem z błędem Forbidden pochodzącym z webhooka autoryzacji Microsoft Entra ID (przy założeniu, że w klastrze zainstalowano CRD Istio; w przeciwnym razie kubectl zwraca błąd „not found”, zanim serwer API dotrze do webhooka autoryzacji).

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

Uprzątnij zasoby

Wyłącz autoryzację Microsoft Entra ID

Usuń autoryzację Microsoft Entra ID za pomocą polecenia az aks update z flagą --disable-azure-rbac.

# 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

Usunięcie przypisania roli

  1. Wyświetlanie listy przydziałów ról przy użyciu polecenia 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. Usuń przypisania ról przy użyciu polecenia az role assignment delete.

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

Usuwanie definicji roli

Usuń niestandardową definicję roli przy użyciu az role definition delete polecenia .

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

Usuń grupę zasobów i klaster AKS

Usuń grupę zasobów (i klaster usługi AKS, który zawiera) przy użyciu az group delete polecenia .

# 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

Aby dowiedzieć się więcej o usłudze AKS, zapoznaj się z następującymi artykułami: