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 ułatwiają definiowanie autoryzacji na platformie Kubernetes natywnie. Za pomocą tej funkcji można użyć usługi Azure Active Directory (Azure AD) i przypisań ról na platformie Azure w celu kontrolowania kontroli 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 Kontrola RBAC platformy Azure w usłudze Azure Arc z włączoną usługą 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 "jak jest" 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ą klienta w oparciu o najlepsze wysiłki.

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 biblioteki 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 Azure Kubernetes Service (AKS) ta funkcja jest dostępna natywnie i nie wymaga połączenia klastra usługi AKS z usługą Azure Arc. W przypadku usługi AKS w usłudze Azure Stack HCI zobacz Używanie kontroli dostępu opartej na rolach platformy Azure dla klastrów hybrydowych usługi AKS (wersja zapoznawcza).

Konfigurowanie aplikacji usługi Azure AD

Tworzenie aplikacji serwera

  1. Utwórz nową aplikację Azure AD 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 logowania i odczytu do aplikacji serwera, skopiuj ten kod JSON i zapisz go w pliku 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 signInAudience ustawienia azureADMyOrg:

    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 obrócić po tym. Aby ustawić niestandardowy czas 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 odczyt profilu użytkownika" do 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ę Azure AD 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 signInAudience ustawienia azureADMyOrg:

        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, w 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 platformy Kubernetes zamiast kontroli dostępu opartej na rolach platformy Azure.

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

  1. Protokół SSH do każdego węzła głównego klastra i wykonaj następujące kroki:

    Jeśli jest to kube-apiserverstatyczny 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 statyczny zasobnik:

    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 jest w wersji 1.19.0 lub nowszej, 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 straży 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 stosujesz 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, aby zaktualizować KubeadmControlPlane obiekt. Poczekaj na wyświetlenie tych zmian 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
Azure Arc Kubernetes Viewer 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 uprawnienie do wpisów tajnych umożliwiłoby dostęp do ServiceAccount poświadczeń w przestrzeni nazw. Te poświadczenia z kolei zezwalałyby na dostęp do interfejsu API za pośrednictwem tej ServiceAccount wartości (forma eskalacji uprawnień).
Składnik zapisywania kubernetes usługi 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 dostęp do wpisów tajnych i uruchamiania 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.
Azure Arc Kubernetes Administracja Zezwala na dostęp administratora. Ma zostać udzielona w przestrzeni nazw za pośrednictwem elementu 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 przydziału zasobów ani do samej przestrzeni nazw.
Administracja klastra Kubernetes usługi Azure Arc Umożliwia dostęp superużytkownika do wykonywania dowolnej akcji w dowolnym zasobie. Gdy używasz go w programie ClusterRoleBinding, zapewnia pełną kontrolę nad każdym zasobem w klastrze i we wszystkich przestrzeniach nazw. Gdy używasz go w programie RoleBinding, 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 klastra Kubernetes z obsługą usługi Azure Arc w Azure Portal w okienku Access Control (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ć nazwa użytkownika (na przykład testuser@mytenant.onmicrosoft.com) lub nawet appId wartość 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 Azure Portal lub interfejsu wiersza polecenia platformy Azure. Jednak tylko interfejs wiersza polecenia platformy Azure może służyć do tworzenia przypisań ról w zakresie przestrzeni nazw.

Role niestandardowe

Możesz utworzyć własną definicję roli do użycia w przypisania 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świetlenie 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 plik 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 cluster Connect (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 z klastrem

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, 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 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 user>config:

    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ędniona w client-go systemach i kubectl. W przypadku nowszych wersji, aby użyć 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 przy użyciu użytkownika usługi Azure Active Directory 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 następujący komunikat o błędzie, 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 Azure AD

Podczas integrowania Azure AD z klastrem Kubernetes z włączoną usługą Azure Arc można również użyć dostępu warunkowego w celu kontrolowania dostępu do klastra.

Uwaga

Azure AD dostęp warunkowy jest funkcją Azure AD Premium.

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

  1. W górnej części Azure Portal wyszukaj i wybierz pozycję Azure Active Directory.

  2. W menu usługi Azure Active Directory 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.

    Zrzut ekranu przedstawiający sposób dodawania zasad dostępu warunkowego w Azure Portal.

  5. Wprowadź nazwę zasad, na przykład arc-k8s-policy.

  6. Wybierz pozycję Użytkownicy i grupy. W obszarze Dołącz 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ę Azure AD, która ma dostęp administracyjny do klastra.

    Zrzut ekranu przedstawiający wybieranie użytkowników lub grup w celu zastosowania zasad dostępu warunkowego.

  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.

    Zrzut ekranu przedstawiający sposób wybierania aplikacji serwera w 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.

    Zrzut ekranu przedstawiający sposób zezwalania tylko na zgodne urządzenia w Azure Portal.

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

    Zrzut ekranu przedstawiający sposób włączania zasad dostępu warunkowego w 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, było zarządzane przez Azure AD w celu uzyskania dostępu do zasobu. Wykonaj następujące kroki:

  1. W witrynie Azure Portal przejdź do pozycji Azure Active Directory.

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

  3. Wpis w górnej części zawiera informację Niepowodzenie dla stanu i powodzeniadostę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.

    Zrzut ekranu przedstawiający nieudany wpis logowania w Azure Portal.

Konfigurowanie dostępu do klastra just in time za pomocą Azure AD

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

Uwaga

Azure AD PIM to funkcja Azure AD Premium, która wymaga jednostki SKU Premium P2. Aby uzyskać więcej informacji na temat Azure AD jednostek SKU, 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 Azure Portal wyszukaj i wybierz pozycję Azure Active Directory.

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

    Zrzut ekranu przedstawiający szczegóły usługi Azure Active Directory w Azure Portal.

  3. W menu usługi Azure Active Directory po lewej stronie w obszarze Zarządzanie wybierz pozycję Grupy>Nowa grupa.

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

    Zrzut ekranu przedstawiający szczegóły nowej grupy w Azure Portal.

  5. Wrócisz 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>.

    Zrzut ekranu przedstawiający identyfikator obiektu dla nowej grupy w Azure Portal.

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

    Zrzut ekranu przedstawiający opcje włączania dostępu uprzywilejowanego w Azure Portal.

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

    Zrzut ekranu przedstawiający sposób dodawania aktywnych przypisań w 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.

    Zrzut ekranu przedstawiający sposób dodawania przypisań w 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 Privileged Identity Management.

    Zrzut ekranu przedstawiający właściwości przypisania w 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ł, należy ją 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 parametry opcjonalne 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