Używanie kontroli dostępu opartej na rolach platformy Azure w klastrach Kubernetes z obsługą usługi Azure Arc (wersja zapoznawcza)

  • Artykuł

Typy obiektów Kubernetes ClusterRoleBinding i RoleBinding pomagają w natywnym zdefiniowaniu autoryzacji na platformie Kubernetes. Za pomocą tej funkcji można użyć identyfikatora Entra firmy Microsoft i przypisań ról na platformie Azure, aby kontrolować kontrole autoryzacji w klastrze. Przypisania ról platformy Azure umożliwiają szczegółową kontrolę nad tym, którzy użytkownicy mogą odczytywać, zapisywać i usuwać obiekty Kubernetes, takie jak wdrażanie, zasobnik i usługa.

Aby zapoznać się z koncepcyjnym omówieniem tej funkcji, zobacz Azure RBAC on Azure Arc-enabled Kubernetes (Kontrola dostępu oparta na rolach platformy Azure w usłudze Azure Arc dla platformy Kubernetes).

Ważne

Funkcje platformy Kubernetes z obsługą usługi Azure Arc w wersji zapoznawczej są dostępne na zasadzie samoobsługi. 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 platformy Kubernetes z obsługą usługi Azure Arc są częściowo objęte pomocą techniczną dla klientów.

Wymagania wstępne

  • Zainstaluj lub uaktualnij interfejs wiersza polecenia platformy Azure do najnowszej wersji.

  • Zainstaluj najnowszą wersję rozszerzenia interfejsu wiersza polecenia platformy connectedk8s Azure:

    az extension add --name connectedk8s

    connectedk8s Jeśli rozszerzenie jest już zainstalowane, możesz zaktualizować je do najnowszej wersji przy użyciu następującego polecenia:

    az extension update --name connectedk8s

  • Połącz się z istniejącym klastrem Kubernetes z obsługą usługi Azure Arc:

Uwaga

Nie można skonfigurować tej funkcji dla rozwiązania Red Hat OpenShift ani dla zarządzanych ofert dostawców usług w chmurze, takich jak Elastic Kubernetes Service lub Google Kubernetes Engine, gdzie użytkownik nie ma dostępu do serwera interfejsu API klastra. W przypadku klastrów usługi Azure Kubernetes Service (AKS) ta funkcja jest dostępna natywnie i nie wymaga połączenia klastra usługi AKS z usługą Azure Arc.

Konfiguracja aplikacji Microsoft Entra

Tworzenie aplikacji serwera

  1. Utwórz nową aplikację Microsoft Entra i uzyskaj jej appId wartość. Ta wartość jest używana w kolejnych krokach jako serverApplicationId.

    CLUSTER_NAME="<name-of-arc-connected-cluster>"
TENANT_ID="<tenant>"
SERVER_UNIQUE_SUFFIX="<identifier_suffix>"
SERVER_APP_ID=$(az ad app create --display-name "${CLUSTER_NAME}Server" --identifier-uris "api://${TENANT_ID}/${SERVER_UNIQUE_SUFFIX}" --query appId -o tsv)
echo $SERVER_APP_ID

  2. Aby przyznać uprawnienia interfejsu API "Zaloguj się i odczyt profilu użytkownika" do aplikacji serwera, skopiuj ten kod JSON i zapisz go w pliku o nazwie oauth2-permissions.json:

    {
    "oauth2PermissionScopes": [
        {
            "adminConsentDescription": "Sign in and read user profile",
            "adminConsentDisplayName": "Sign in and read user profile",
            "id": "<paste_the_SERVER_APP_ID>",
            "isEnabled": true,
            "type": "User",
            "userConsentDescription": "Sign in and read user profile",
            "userConsentDisplayName": "Sign in and read user profile",
            "value": "User.Read"
        }
    ]
}

  3. Zaktualizuj oświadczenia członkostwa w grupie aplikacji. Uruchom polecenia w tym samym katalogu co oauth2-permissions.json plik. Kontrola dostępu oparta na rolach dla platformy Kubernetes z obsługą usługi Azure Arc wymaga ustawienia azureADMyOrg:signInAudience

    az ad app update --id "${SERVER_APP_ID}" --set groupMembershipClaims=All
az ad app update --id ${SERVER_APP_ID} --set  api=@oauth2-permissions.json
az ad app update --id ${SERVER_APP_ID} --set  signInAudience=AzureADMyOrg
SERVER_OBJECT_ID=$(az ad app show --id "${SERVER_APP_ID}" --query "id" -o tsv)
az rest --method PATCH --headers "Content-Type=application/json" --uri https://graph.microsoft.com/v1.0/applications/${SERVER_OBJECT_ID}/ --body '{"api":{"requestedAccessTokenVersion": 1}}'

  4. Utwórz jednostkę usługi i pobierz jej password wartość pola. Ta wartość jest wymagana później, gdy serverApplicationSecret włączysz tę funkcję w klastrze. Ten wpis tajny jest domyślnie ważny przez jeden rok i należy go później obrócić. Aby ustawić niestandardowy czas trwania wygaśnięcia, użyj polecenia az ad sp credential reset:

    az ad sp create --id "${SERVER_APP_ID}"
SERVER_APP_SECRET=$(az ad sp credential reset --id "${SERVER_APP_ID}"  --query password -o tsv)

  5. Udziel uprawnień interfejsu API "Zaloguj się i odczytaj profil użytkownika" aplikacji przy użyciu polecenia az ad app permission:

    az ad app permission add --id "${SERVER_APP_ID}" --api 00000003-0000-0000-c000-000000000000 --api-permissions e1fe6dd8-ba31-4d61-89e7-88639da4683d=Scope
az ad app permission grant --id "${SERVER_APP_ID}" --api 00000003-0000-0000-c000-000000000000 --scope User.Read

    Uwaga

    Administrator aplikacji platformy Azure musi uruchomić ten krok.

    W przypadku użycia tej funkcji w środowisku produkcyjnym zalecamy utworzenie innej aplikacji serwera dla każdego klastra.

Tworzenie aplikacji klienckiej

  1. Utwórz nową aplikację Microsoft Entra i uzyskaj jej appId wartość. Ta wartość jest używana w kolejnych krokach jako clientApplicationId.

    CLIENT_UNIQUE_SUFFIX="<identifier_suffix>" 
CLIENT_APP_ID=$(az ad app create --display-name "${CLUSTER_NAME}Client" --is-fallback-public-client --public-client-redirect-uris "api://${TENANT_ID}/${CLIENT_UNIQUE_SUFFIX}" --query appId -o tsv)
echo $CLIENT_APP_ID

  2. Utwórz jednostkę usługi dla tej aplikacji klienckiej:

    az ad sp create --id "${CLIENT_APP_ID}"

  3. oAuthPermissionId Pobierz wartość aplikacji serwera:

        az ad app show --id "${SERVER_APP_ID}" --query "api.oauth2PermissionScopes[0].id" -o tsv

  4. Udziel wymaganych uprawnień dla aplikacji klienckiej. Kontrola dostępu oparta na rolach dla platformy Kubernetes z obsługą usługi Azure Arc wymaga ustawienia azureADMyOrg:signInAudience

        az ad app permission add --id "${CLIENT_APP_ID}" --api "${SERVER_APP_ID}" --api-permissions <oAuthPermissionId>=Scope
    RESOURCE_APP_ID=$(az ad app show --id "${CLIENT_APP_ID}"  --query "requiredResourceAccess[0].resourceAppId" -o tsv)
    az ad app permission grant --id "${CLIENT_APP_ID}" --api "${RESOURCE_APP_ID}" --scope User.Read
    az ad app update --id ${CLIENT_APP_ID} --set  signInAudience=AzureADMyOrg
    CLIENT_OBJECT_ID=$(az ad app show --id "${CLIENT_APP_ID}" --query "id" -o tsv)
    az rest --method PATCH --headers "Content-Type=application/json" --uri https://graph.microsoft.com/v1.0/applications/${CLIENT_OBJECT_ID}/ --body '{"api":{"requestedAccessTokenVersion": 1}}'

Tworzenie przypisania roli dla aplikacji serwera

Aplikacja serwera potrzebuje Microsoft.Authorization/*/read uprawnień, aby potwierdzić, że użytkownik wysyłający żądanie jest autoryzowany w obiektach Kubernetes uwzględnionych w żądaniu.

  1. Utwórz plik o nazwie accessCheck.json z następującą zawartością:

    {
"Name": "Read authorization",
"IsCustom": true,
"Description": "Read authorization",
"Actions": ["Microsoft.Authorization/*/read"],
"NotActions": [],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": [
  "/subscriptions/<subscription-id>"
  ]
}

    Zastąp <subscription-id> element rzeczywistym identyfikatorem subskrypcji.

  2. Uruchom następujące polecenie, aby utworzyć nową rolę niestandardową:

    ROLE_ID=$(az role definition create --role-definition ./accessCheck.json --query id -o tsv)

  3. Utwórz przypisanie roli w aplikacji serwera jako assignee przy użyciu utworzonej roli:

    az role assignment create --role "${ROLE_ID}" --assignee "${SERVER_APP_ID}" --scope /subscriptions/<subscription-id>

Włączanie kontroli dostępu na podstawie ról platformy Azure w klastrze

Włącz kontrolę dostępu opartą na rolach (RBAC) platformy Azure w klastrze Kubernetes z obsługą usługi Azure Arc, uruchamiając następujące polecenie:

az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac --app-id "${SERVER_APP_ID}" --app-secret "${SERVER_APP_SECRET}"

Uwaga

Przed uruchomieniem poprzedniego polecenia upewnij się, że kubeconfig plik na maszynie wskazuje klaster, na którym włączysz funkcję RBAC platformy Azure.

Użyj --skip-azure-rbac-list z poprzednim poleceniem dla rozdzielanej przecinkami listy nazw użytkowników, wiadomości e-mail i połączeń OpenID poddawanych kontroli autoryzacji przy użyciu funkcji natywnej ClusterRoleBinding i RoleBinding obiektów kubernetes zamiast kontroli dostępu opartej na rolach platformy Azure.

Klaster ogólny, w którym w specyfikacji apiserver nie jest uruchomiony żaden uzgadnianie

  1. Połączenie SSH z każdym węzłem głównym klastra i wykonaj następujące czynności:

    kube-apiserver Jeśli jest to statyczny zasobnik:

    1. Wpis azure-arc-guard-manifests tajny w kube-system przestrzeni nazw zawiera dwa pliki: guard-authn-webhook.yaml i guard-authz-webhook.yaml. Skopiuj te pliki do /etc/guard katalogu węzła.

      sudo mkdir -p /etc/guard
kubectl get secrets azure-arc-guard-manifests -n kube-system -o json | jq -r '.data."guard-authn-webhook.yaml"' | base64 -d > /etc/guard/guard-authn-webhook.yaml
kubectl get secrets azure-arc-guard-manifests -n kube-system -o json | jq -r '.data."guard-authz-webhook.yaml"' | base64 -d > /etc/guard/guard-authz-webhook.yaml

    2. Otwórz manifest w trybie edycji apiserver :

      sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml

    3. Dodaj następującą specyfikację w obszarze volumes:

      - name: azure-rbac
    hostPath:
    path: /etc/guard
    type: Directory

    4. Dodaj następującą specyfikację w obszarze volumeMounts:

      - mountPath: /etc/guard
    name: azure-rbac
    readOnly: true

    Jeśli nie kube-apiserver jest to zasobnik statyczny:

    1. Otwórz manifest w trybie edycji apiserver :

      sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml

    2. Dodaj następującą specyfikację w obszarze volumes:

      - name: azure-rbac
    secret:
    secretName: azure-arc-guard-manifests

    3. Dodaj następującą specyfikację w obszarze volumeMounts:

      - mountPath: /etc/guard
    name: azure-rbac
    readOnly: true

  2. Dodaj następujące apiserver argumenty:

    - --authentication-token-webhook-config-file=/etc/guard/guard-authn-webhook.yaml
- --authentication-token-webhook-cache-ttl=5m0s
- --authorization-webhook-cache-authorized-ttl=5m0s
- --authorization-webhook-config-file=/etc/guard/guard-authz-webhook.yaml
- --authorization-webhook-version=v1
- --authorization-mode=Node,RBAC,Webhook

    Jeśli klaster Kubernetes ma wersję 1.19.0 lub nowszą, należy również ustawić następujący apiserver argument:

    - --authentication-token-webhook-version=v1

  3. Zapisz i zamknij edytor, aby zaktualizować apiserver zasobnik.

Klaster utworzony przy użyciu interfejsu API klastra

  1. Skopiuj wpis tajny ochrony zawierający pliki konfiguracji elementu webhook uwierzytelniania i autoryzacji z klastra obciążenia na maszynę:

    kubectl get secret azure-arc-guard-manifests -n kube-system -o yaml > azure-arc-guard-manifests.yaml

  2. namespace Zmień pole w pliku azure-arc-guard-manifests.yaml na przestrzeń nazw w klastrze zarządzania, w którym są stosowane zasoby niestandardowe do tworzenia klastrów obciążeń.

  3. Zastosuj ten manifest:

    kubectl apply -f azure-arc-guard-manifests.yaml

  4. Edytuj obiekt, KubeadmControlPlane uruchamiając polecenie kubectl edit kcp <clustername>-control-plane:

    1. Dodaj następujący fragment kodu w obszarze files:

      - contentFrom:
    secret:
      key: guard-authn-webhook.yaml
      name: azure-arc-guard-manifests
  owner: root:root
  path: /etc/kubernetes/guard-authn-webhook.yaml
  permissions: "0644"
- contentFrom:
    secret:
      key: guard-authz-webhook.yaml
      name: azure-arc-guard-manifests
  owner: root:root
  path: /etc/kubernetes/guard-authz-webhook.yaml
  permissions: "0644"

    2. Dodaj następujący fragment kodu w obszarze apiServer>extraVolumes:

      - hostPath: /etc/kubernetes/guard-authn-webhook.yaml
    mountPath: /etc/guard/guard-authn-webhook.yaml
    name: guard-authn
    readOnly: true
- hostPath: /etc/kubernetes/guard-authz-webhook.yaml
    mountPath: /etc/guard/guard-authz-webhook.yaml
    name: guard-authz
    readOnly: true

    3. Dodaj następujący fragment kodu w obszarze apiServer>extraArgs:

      authentication-token-webhook-cache-ttl: 5m0s
authentication-token-webhook-config-file: /etc/guard/guard-authn-webhook.yaml
authentication-token-webhook-version: v1
authorization-mode: Node,RBAC,Webhook
authorization-webhook-cache-authorized-ttl: 5m0s
authorization-webhook-config-file: /etc/guard/guard-authz-webhook.yaml
authorization-webhook-version: v1

    4. Zapisz i zamknij, KubeadmControlPlane aby zaktualizować obiekt. Poczekaj, aż te zmiany pojawią się w klastrze obciążenia.

Tworzenie przypisań ról dla użytkowników w celu uzyskania dostępu do klastra

Właściciele zasobu Kubernetes z obsługą usługi Azure Arc mogą używać wbudowanych ról lub ról niestandardowych, aby udzielić innym użytkownikom dostępu do klastra Kubernetes.

Wbudowane role

Rola opis
Podgląd platformy Kubernetes w usłudze Azure Arc Umożliwia dostęp tylko do odczytu, aby wyświetlić większość obiektów w przestrzeni nazw. Ta rola nie zezwala na wyświetlanie wpisów tajnych, ponieważ read uprawnienia do wpisów tajnych umożliwiają dostęp do ServiceAccount poświadczeń w przestrzeni nazw. Te poświadczenia z kolei zezwalają na dostęp do interfejsu API za pośrednictwem tej ServiceAccount wartości (forma eskalacji uprawnień).
Składnik zapisywania platformy Kubernetes w usłudze Azure Arc 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 uzyskiwanie dostępu do wpisów tajnych i uruchamianie zasobników jako dowolnej ServiceAccount wartości w przestrzeni nazw, dzięki czemu może służyć do uzyskiwania poziomów dostępu interfejsu API dowolnej ServiceAccount wartości w przestrzeni nazw.
Usługa Azure Arc Kubernetes Administracja Zezwala na dostęp administratora. Ma zostać udzielona w przestrzeni nazw za pośrednictwem .RoleBinding Jeśli używasz go w RoleBindingprogramie , umożliwia dostęp do odczytu/zapisu do większości zasobów w przestrzeni nazw, w tym możliwość tworzenia ról i powiązań ról w przestrzeni nazw. Ta rola nie zezwala na dostęp do zapisu do limitu przydziału zasobów ani do samej przestrzeni nazw.
Administracja klastra Kubernetes usługi Azure Arc Umożliwia dostęp administratora do wykonywania dowolnej akcji na dowolnym zasobie. Gdy używasz go w ClusterRoleBindingprogramie , zapewnia pełną kontrolę nad każdym zasobem w klastrze i we wszystkich przestrzeniach nazw. Gdy używasz go w RoleBindingprogramie , zapewnia pełną kontrolę nad każdym zasobem w przestrzeni nazw powiązania roli, w tym nad samą przestrzenią nazw.

Przypisania ról można tworzyć w zakresie do klastra Kubernetes z włączoną usługą Azure Arc w witrynie Azure Portal w okienku Kontrola dostępu (IAM) zasobu klastra. Możesz również użyć następujących poleceń interfejsu wiersza polecenia platformy Azure:

az role assignment create --role "Azure Arc Kubernetes Cluster Admin" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID

W tych poleceniach AZURE-AD-ENTITY-ID może być nazwą użytkownika (na przykład testuser@mytenant.onmicrosoft.com), a nawet appId wartością jednostki usługi.

Oto kolejny przykład tworzenia przypisania roli o określonym zakresie w określonej przestrzeni nazw w klastrze:

az role assignment create --role "Azure Arc Kubernetes Viewer" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID/namespaces/<namespace-name>

Uwaga

Przypisania ról można tworzyć w zakresie klastra przy użyciu witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure. Można jednak używać tylko interfejsu wiersza polecenia platformy Azure do tworzenia przypisań ról w zakresie przestrzeni nazw.

Role niestandardowe

Możesz utworzyć własną definicję roli do użycia w przypisaniach ról.

Zapoznaj się z poniższym przykładem definicji roli, która umożliwia użytkownikowi odczytywanie tylko wdrożeń. Aby uzyskać więcej informacji, zobacz pełną listę akcji danych, których można użyć do konstruowania definicji roli.

Skopiuj następujący obiekt JSON do pliku o nazwie custom-role.json. Zastąp <subscription-id> symbol zastępczy rzeczywistym identyfikatorem subskrypcji. Rola niestandardowa używa jednej z akcji danych i umożliwia wyświetlanie wszystkich wdrożeń w zakresie (klastrze lub przestrzeni nazw), w którym jest tworzone przypisanie roli.

{
    "Name": "Arc Deployment Viewer",
    "Description": "Lets you view all deployments in cluster/namespace.",
    "Actions": [],
    "NotActions": [],
    "DataActions": [
        "Microsoft.Kubernetes/connectedClusters/apps/deployments/read"
    ],
    "NotDataActions": [],
    "assignableScopes": [
        "/subscriptions/<subscription-id>"
    ]
}

  1. Utwórz definicję roli, uruchamiając następujące polecenie z folderu, w którym zapisano custom-role.json:

    az role definition create --role-definition @custom-role.json

  2. Utwórz przypisanie roli przy użyciu tej niestandardowej definicji roli:

    az role assignment create --role "Arc Deployment Viewer" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID/namespaces/<namespace-name>

Konfigurowanie narzędzia kubectl przy użyciu poświadczeń użytkownika

Istnieją dwa sposoby uzyskiwania pliku kubeconfig potrzebnego do uzyskania dostępu do klastra:

  • Używasz funkcji Połączenie klastra (az connectedk8s proxy) klastra Kubernetes z obsługą usługi Azure Arc.
  • Administrator klastra współużytkuje plik kubeconfig ze wszystkimi innymi użytkownikami.

Korzystanie z połączenia klastra

Uruchom następujące polecenie, aby uruchomić proces serwera proxy:

az connectedk8s proxy -n <clusterName> -g <resourceGroupName>

Po uruchomieniu procesu serwera proxy możesz otworzyć inną kartę w konsoli programu , aby rozpocząć wysyłanie żądań do klastra.

Używanie udostępnionego pliku kubeconfig

Użycie udostępnionej konfiguracji kubeconfig wymaga nieco różnych kroków w zależności od wersji platformy Kubernetes.

  1. Uruchom następujące polecenie, aby ustawić poświadczenia dla użytkownika:

    kubectl config set-credentials <testuser>@<mytenant.onmicrosoft.com> \
--auth-provider=azure \
--auth-provider-arg=environment=AzurePublicCloud \
--auth-provider-arg=client-id=<clientApplicationId> \
--auth-provider-arg=tenant-id=<tenantId> \
--auth-provider-arg=apiserver-id=<serverApplicationId>

  2. Otwórz utworzony wcześniej plik kubeconfig. W obszarze contextssprawdź, czy kontekst skojarzony z klastrem wskazuje poświadczenia użytkownika utworzone w poprzednim kroku. Aby ustawić bieżący kontekst na te poświadczenia użytkownika, uruchom następujące polecenie:

    kubectl config set-context --current=true --user=<testuser>@<mytenant.onmicrosoft.com>

  3. Dodaj ustawienie trybu konfiguracji w obszarze>userconfig :

    name: testuser@mytenant.onmicrosoft.com
user:
    auth-provider:
    config:
        apiserver-id: $SERVER_APP_ID
        client-id: $CLIENT_APP_ID
        environment: AzurePublicCloud
        tenant-id: $TENANT_ID
        config-mode: "1"
    name: azure

Uwaga

Wtyczka Exec to strategia uwierzytelniania platformy Kubernetes, która umożliwia kubectl wykonywanie zewnętrznego polecenia w celu odbierania poświadczeń użytkownika do wysyłania do apiserverusługi . Począwszy od platformy Kubernetes w wersji 1.26, domyślna wtyczka autoryzacji platformy Azure nie jest już uwzględniana w systemach client-go i kubectl. W przypadku nowszych wersji, aby używać wtyczki exec do odbierania poświadczeń użytkownika, należy użyć wtyczki Azure Kubelogin, client-go wtyczki poświadczeń (exec), która implementuje uwierzytelnianie platformy Azure.

  1. Zainstaluj usługę Azure Kubelogin:

    • W przypadku systemu Windows lub Mac postępuj zgodnie z instrukcjami instalacji usługi Azure Kubelogin.

    • W przypadku systemu Linux lub Ubuntu pobierz najnowszą wersję narzędzia kubelogin, a następnie uruchom następujące polecenia:

      curl -LO https://github.com/Azure/kubelogin/releases/download/"$KUBELOGIN_VERSION"/kubelogin-linux-amd64.zip 

unzip kubelogin-linux-amd64.zip 

sudo mv bin/linux_amd64/kubelogin /usr/local/bin/ 

sudo chmod +x /usr/local/bin/kubelogin

  2. Przekonwertuj kubelogin, aby użyć odpowiedniego trybu logowania. Na przykład w przypadku logowania kodu urządzenia z użytkownikiem firmy Microsoft Entra polecenia będą następujące:

    export KUBECONFIG=/path/to/kubeconfig

kubelogin convert-kubeconfig

Wysyłanie żądań do klastra

  1. Uruchom dowolne kubectl polecenie. Na przykład:

    • kubectl get nodes
    • kubectl get pods

  2. Po wyświetleniu monitu o uwierzytelnienie oparte na przeglądarce skopiuj adres URL logowania urządzenia (https://microsoft.com/devicelogin) i otwórz go w przeglądarce internetowej.

  3. Wprowadź kod wydrukowany w konsoli. Skopiuj i wklej kod w terminalu do monitu o wprowadzenie uwierzytelniania urządzenia.

  4. Wprowadź nazwę użytkownika (testuser@mytenant.onmicrosoft.com) i skojarzone hasło.

  5. Jeśli zostanie wyświetlony komunikat o błędzie podobny do tego, oznacza to, że nie masz autoryzacji dostępu do żądanego zasobu:

    Error from server (Forbidden): nodes is forbidden: User "testuser@mytenant.onmicrosoft.com" cannot list resource "nodes" in API group "" at the cluster scope: User doesn't have access to the resource in Azure. Update role assignment to allow access.

    Administrator musi utworzyć nowe przypisanie roli, które autoryzuje tego użytkownika do uzyskania dostępu do zasobu.

Używanie dostępu warunkowego z identyfikatorem Entra firmy Microsoft

Podczas integrowania identyfikatora Entra firmy Microsoft z klastrem Kubernetes z włączoną usługą Azure Arc możesz również użyć dostępu warunkowego, aby kontrolować dostęp do klastra.

Uwaga

Microsoft Entra Conditional Access to funkcja microsoft Entra ID P2.

Aby utworzyć przykładowe zasady dostępu warunkowego do użycia z klastrem:

  1. W górnej części witryny Azure Portal wyszukaj i wybierz pozycję Microsoft Entra ID.

  2. W menu microsoft Entra ID po lewej stronie wybierz pozycję Aplikacje dla przedsiębiorstw.

  3. W menu aplikacji dla przedsiębiorstw po lewej stronie wybierz pozycję Dostęp warunkowy.

  4. W menu dostępu warunkowego po lewej stronie wybierz pozycję Zasady>Nowe zasady.

    Screenshot showing how to add a conditional access policy in the Azure portal.

  5. Wprowadź nazwę zasad, taką jak arc-k8s-policy.

  6. Wybierz pozycję Użytkownicy i grupy. W obszarze Uwzględnij wybierz pozycję Wybierz użytkowników i grupy. Następnie wybierz użytkowników i grupy, w których chcesz zastosować zasady. W tym przykładzie wybierz tę samą grupę firmy Microsoft Entra, która ma dostęp administracyjny do klastra.

    Screenshot that shows selecting users or groups to apply the Conditional Access policy.

  7. Wybierz pozycję Aplikacje w chmurze lub akcje. W obszarze Dołącz wybierz pozycję Wybierz aplikacje. Następnie wyszukaj i wybierz utworzoną wcześniej aplikację serwera.

    Screenshot showing how to select a server application in the Azure portal.

  8. W obszarze Kontrole dostępu wybierz pozycję Udziel. Wybierz pozycję Udziel dostępu>Wymagaj, aby urządzenie było oznaczone jako zgodne.

    Screenshot showing how to allow only compliant devices in the Azure portal.

  9. W obszarze Włącz zasady wybierz pozycję Przy>tworzeniu.

    Screenshot showing how to enable a conditional access policy in the Azure portal.

Ponownie uzyskaj dostęp do klastra. Na przykład uruchom kubectl get nodes polecenie , aby wyświetlić węzły w klastrze:

kubectl get nodes

Postępuj zgodnie z instrukcjami, aby zalogować się ponownie. Komunikat o błędzie informuje o pomyślnym zalogowaniu, ale administrator wymaga, aby urządzenie, które żąda dostępu do zarządzania za pomocą identyfikatora Entra firmy Microsoft, aby uzyskać dostęp do zasobu. Wykonaj te kroki:

  1. W witrynie Azure Portal przejdź do pozycji Microsoft Entra ID.

  2. Wybierz pozycję Aplikacje dla przedsiębiorstw. Następnie w obszarze Działanie wybierz pozycję Logowania.

  3. Wpis w górnej części zawiera wartość Niepowodzenie dla pozycji Stan i Powodzeniedostępu warunkowego. Wybierz wpis, a następnie wybierz pozycję Dostęp warunkowy w obszarze Szczegóły. Zwróć uwagę, że twoje zasady dostępu warunkowego znajdują się na liście.

    Screenshot showing a failed sign-in entry in the Azure portal.

Konfigurowanie dostępu do klastra just in time przy użyciu identyfikatora Entra firmy Microsoft

Inną opcją kontroli dostępu do klastra jest użycie usługi Privileged Identity Management (PIM) dla żądań just in time.

Uwaga

Microsoft Entra PIM to funkcja Microsoft Entra ID P2. Aby uzyskać więcej informacji na temat jednostek SKU identyfikatorów entra firmy Microsoft, zobacz przewodnik po cenach.

Aby skonfigurować żądania dostępu just in time dla klastra, wykonaj następujące kroki:

  1. W górnej części witryny Azure Portal wyszukaj i wybierz pozycję Microsoft Entra ID.

  2. Zanotuj identyfikator dzierżawy. W pozostałej części tych instrukcji będziemy odwoływać się do tego identyfikatora jako <tenant-id>.

    Screenshot showing Microsoft Entra ID details in the Azure portal.

  3. W menu microsoft Entra ID po lewej stronie w obszarze Zarządzaj wybierz pozycję Grupy>Nowa grupa.

  4. Upewnij się, że dla opcji Typ grupy wybrano pozycję Zabezpieczenia. Wprowadź nazwę grupy, taką jak myJITGroup. W obszarze Role entra firmy Microsoft można przypisać do tej grupy (wersja zapoznawcza) wybierz pozycję Tak. Na koniec wybierz pozycję Utwórz.

    Screenshot showing details for the new group in the Azure portal.

  5. Zostaniesz przywrócony do strony Grupy . Wybierz nowo utworzoną grupę i zanotuj identyfikator obiektu. W pozostałej części tych instrukcji będziemy odwoływać się do tego identyfikatora jako <object-id>.

    Screenshot showing the object ID for the new group in the Azure portal.

  6. W witrynie Azure Portal w menu Działania po lewej stronie wybierz pozycję Uprzywilejowany dostęp (wersja zapoznawcza). Następnie wybierz pozycję Włącz dostęp uprzywilejowany.

    Screenshot showing selections for enabling privileged access in the Azure portal.

  7. Wybierz pozycję Dodaj przypisania , aby rozpocząć udzielanie dostępu.

    Screenshot showing how to add active assignments in the Azure portal.

  8. Wybierz rolę Członek i wybierz użytkowników i grupy, którym chcesz udzielić dostępu do klastra. Administrator grupy może w dowolnym momencie modyfikować te przypisania. Gdy wszystko będzie gotowe do przejścia, wybierz pozycję Dalej.

    Screenshot showing how to add assignments in the Azure portal.

  9. Wybierz typ przypisania Aktywny, wybierz żądany czas trwania i podaj uzasadnienie. Gdy wszystko będzie gotowe do kontynuowania, wybierz pozycję Przypisz. Aby uzyskać więcej informacji na temat typów przypisań, zobacz Przypisywanie uprawnień do uprzywilejowanej grupy dostępu (wersja zapoznawcza) w usłudze Privileged Identity Management.

    Screenshot showing assignment properties in the Azure portal.

Po utworzeniu przypisań sprawdź, czy dostęp just in time działa, korzystając z klastra. Na przykład użyj kubectl get nodes polecenia , aby wyświetlić węzły w klastrze:

kubectl get nodes

Zwróć uwagę na wymaganie dotyczące uwierzytelniania i wykonaj kroki uwierzytelniania. Jeśli uwierzytelnianie zakończy się pomyślnie, powinny zostać wyświetlone dane wyjściowe podobne do następujących:

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code AAAAAAAAA to authenticate.

NAME      STATUS   ROLES    AGE      VERSION
node-1    Ready    agent    6m36s    v1.18.14
node-2    Ready    agent    6m42s    v1.18.14
node-3    Ready    agent    6m33s    v1.18.14

Odświeżanie wpisu tajnego aplikacji serwera

Jeśli wpis tajny jednostki usługi aplikacji serwera wygasł, musisz go obrócić.

SERVER_APP_SECRET=$(az ad sp credential reset --name "${SERVER_APP_ID}" --credential-description "ArcSecret" --query password -o tsv)

Zaktualizuj wpis tajny w klastrze. Uwzględnij wszystkie opcjonalne parametry skonfigurowane podczas uruchamiania polecenia.

az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac --app-id "${SERVER_APP_ID}" --app-secret "${SERVER_APP_SECRET}"

Następne kroki