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

Artykuł
11/02/2024

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).

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:
- Jeśli nie nawiązano jeszcze połączenia z klastrem, skorzystaj z naszego przewodnika Szybki start.
- Uaktualnij agentów do najnowszej wersji.

Uwaga

Kontrola dostępu oparta na rolach platformy Azure nie jest dostępna w przypadku ofert Red Hat OpenShift lub zarządzanych platformy Kubernetes, w których dostęp użytkownika do serwera interfejsu API jest ograniczony (np. Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE)).

Kontrola dostępu oparta na rolach platformy Azure nie obsługuje obecnie klastrów Kubernetes działających w architekturze ARM64. Użyj kontroli dostępu na podstawie ról platformy Kubernetes do zarządzania kontrolą dostępu dla klastrów Kubernetes opartych na usłudze ARM64.

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.

W przypadku klastrów usługi Azure Kubernetes Service (AKS) obsługiwanych przez usługę Azure Arc w usłudze Azure Stack HCI 23H2 włączenie kontroli dostępu opartej na rolach platformy Azure jest obecnie obsługiwane tylko podczas tworzenia klastra Kubernetes. Aby utworzyć klaster usługi AKS włączony przez usługę Azure Arc z włączoną kontrolą dostępu opartą na rolach platformy Azure, postępuj zgodnie z przewodnikiem Używanie kontroli dostępu opartej na rolach platformy Azure dla platformy Kubernetes. Należy pamiętać, że kontrola dostępu oparta na rolach platformy Azure nie jest obsługiwana w przypadku usługi Azure Stack HCI w wersji 22H2.

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

Pobierz tożsamość usługi zarządzanej klastra, uruchamiając następujące polecenie:
```
az connectedk8s show -g <resource-group> -n <connected-cluster-name>
```
Pobierz identyfikator (identity.principalId) z danych wyjściowych i uruchom następujące polecenie, aby przypisać rolę czytelnika tożsamości zarządzanej połączonego klastra do tożsamości zarządzanej klastra:
```
az role assignment create --role "Connected Cluster Managed Identity CheckAccess Reader" --assignee "<Cluster MSI ID>" --scope <cluster ARM ID>
```
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
```
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

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:

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

Otwórz manifest w trybie edycji apiserver :

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

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

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

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:

Otwórz manifest w trybie edycji apiserver :

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

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

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

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

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

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

Zapisz i zamknij edytor, aby zaktualizować apiserver zasobnik.

Klaster utworzony przy użyciu interfejsu API klastra

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
```
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ń.

Zastosuj ten manifest:

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

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

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"

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

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

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.
Administrator usługi Azure Arc Kubernetes	Zezwala na dostęp administratora. Ma zostać udzielona w przestrzeni nazw za pośrednictwem .`RoleBinding` Jeśli używasz go w `RoleBinding`programie , 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.
Administrator klastra Kubernetes w usłudze Azure Arc	Umożliwia dostęp administratora do wykonywania dowolnej akcji na dowolnym zasobie. Gdy używasz go w `ClusterRoleBinding`programie , zapewnia pełną kontrolę nad każdym zasobem w klastrze i we wszystkich przestrzeniach nazw. Gdy używasz go w `RoleBinding`programie , 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>"
    ]
}

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
```

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 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.

Wersja >platformy Kubernetes = 1.26
Kubernetes < v1.26

Uruchom następujące polecenie, aby ustawić poświadczenia dla użytkownika. Określ serverApplicationId jako 6256c85f-0aad-4d50-b960-e6e9b21efe35 i clientApplicationId jako 3f4439ff-e698-4d6d-84fe-09c9d574f06b:

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>

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>
```
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.
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 
```
Platforma Kubelogin może służyć do uwierzytelniania za pomocą klastrów z obsługą usługi Azure Arc, żądając tokenu weryfikacji posiadania (PoP). Przekonwertuj narzędzie kubeconfig przy użyciu narzędzia 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 --pop-enabled --pop-claims 'u=<ARM ID of cluster>"
```

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>

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>
```

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

Wysyłanie żądań do klastra

Uruchom dowolne kubectl polecenie. Na przykład:
- kubectl get nodes
- kubectl get pods
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.
Wprowadź kod wydrukowany w konsoli. Skopiuj i wklej kod w terminalu do monitu o wprowadzenie uwierzytelniania urządzenia.
Wprowadź nazwę użytkownika (testuser@mytenant.onmicrosoft.com) i skojarzone hasło.
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:

W górnej części witryny Azure Portal wyszukaj i wybierz pozycję Microsoft Entra ID.
W menu microsoft Entra ID po lewej stronie wybierz pozycję Aplikacje dla przedsiębiorstw.
W menu aplikacji dla przedsiębiorstw po lewej stronie wybierz pozycję Dostęp warunkowy.
W menu dostępu warunkowego po lewej stronie wybierz pozycję Zasady>Nowe zasady.
Wprowadź nazwę zasad, taką jak arc-k8s-policy.
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.
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.
W obszarze Kontrole dostępu wybierz pozycję Udziel. Wybierz pozycję Udziel dostępu>Wymagaj, aby urządzenie było oznaczone jako zgodne.
W obszarze Włącz zasady wybierz pozycję Przy>tworzeniu.

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:

W witrynie Azure Portal przejdź do pozycji Microsoft Entra ID.
Wybierz pozycję Aplikacje dla przedsiębiorstw. Następnie w obszarze Działanie wybierz pozycję Logowania.
Wpis w górnej części zawiera wartość Niepowodzenie dla pozycji Stan i Powodzenie dostę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.

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:

W górnej części witryny Azure Portal wyszukaj i wybierz pozycję Microsoft Entra ID.
Zanotuj identyfikator dzierżawy. W pozostałej części tych instrukcji będziemy odwoływać się do tego identyfikatora jako <tenant-id>.
W menu microsoft Entra ID po lewej stronie w obszarze Zarządzaj wybierz pozycję Grupy>Nowa grupa.
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.
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>.
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.
Wybierz pozycję Dodaj przypisania , aby rozpocząć udzielanie dostępu.
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.
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.

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

Następne kroki

Bezpiecznie nawiąż połączenie z klastrem przy użyciu narzędzia Cluster Connect.
Przeczytaj o architekturze kontroli dostępu opartej na rolach platformy Azure na platformie Kubernetes z obsługą usługi Arc.

Udostępnij za pośrednictwem

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

Wymagania wstępne

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

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

Klaster utworzony przy użyciu interfejsu API klastra

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

Wbudowane role

Role niestandardowe

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

Korzystanie z połączenia klastra

Używanie udostępnionego pliku kubeconfig

Wysyłanie żądań do klastra

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

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

Następne kroki

Opinia

Dodatkowe zasoby

Udostępnij za pośrednictwem

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

Wymagania wstępne

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

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

Klaster utworzony przy użyciu interfejsu API klastra

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

Wbudowane role

Role niestandardowe

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

Korzystanie z połączenia klastra

Używanie udostępnionego pliku kubeconfig

Wysyłanie żądań do klastra

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

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

Następne kroki

Opinia

Dodatkowe zasoby

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