Kontrolowanie dostępu przy użyciu identyfikatora Entra firmy Microsoft i kontroli dostępu opartej na rolach platformy Kubernetes

Dotyczy: usługa AKS w usłudze Azure Stack HCI 23H2

Usługę Azure Kubernetes Service (AKS) można skonfigurować do uwierzytelniania użytkowników przy użyciu identyfikatora Entra firmy Microsoft. W tej konfiguracji logujesz się do klastra Kubernetes przy użyciu tokenu uwierzytelniania Entra firmy Microsoft. Po uwierzytelnieniu można użyć wbudowanej kontroli dostępu opartej na rolach platformy Kubernetes (Kubernetes RBAC) do zarządzania dostępem do przestrzeni nazw i zasobów klastra na podstawie tożsamości użytkownika lub członkostwa w grupie.

W tym artykule opisano sposób kontrolowania dostępu przy użyciu kontroli dostępu opartej na rolach platformy Kubernetes w klastrze Kubernetes na podstawie członkostwa w grupie Microsoft Entra w usłudze AKS. Utworzysz grupę demonstracyjną i użytkowników w identyfikatorze Entra firmy Microsoft. Następnie utworzysz role i powiązania ról w klastrze, aby przyznać odpowiednie uprawnienia do tworzenia i wyświetlania zasobów.

Wymagania wstępne

Przed skonfigurowaniem kontroli dostępu opartej na rolach platformy Kubernetes przy użyciu identyfikatora Entra firmy Microsoft należy spełnić następujące wymagania wstępne:

• Usługa AKS włączona przez klaster usługi Azure Arc. Jeśli musisz skonfigurować klaster, zapoznaj się z instrukcjami dotyczącymi korzystania z witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure.

• Potrzebny jest zainstalowany i skonfigurowany interfejs wiersza polecenia platformy Azure. Jeśli konieczna będzie instalacja lub uaktualnienie, zobacz Instalowanie interfejsu wiersza polecenia platformy Azure.

• Zainstaluj najnowszą wersję rozszerzeń interfejsu aksarc wiersza polecenia platformy Azure:connectedk8s

  az extension add --name aksarc
  az extension add --name connectedk8s
  

  Jeśli rozszerzenie jest aksarc już zainstalowane, zaktualizuj rozszerzenie do najnowszej wersji:

  az extension update --name aksarc
  az extension update --name connectedk8s
  

• Kubectl. Narzędzie wiersza polecenia Kubernetes kubectl umożliwia uruchamianie poleceń przeznaczonych dla klastrów Kubernetes. Aby sprawdzić, czy zainstalowano narzędzie kubectl, otwórz wiersz polecenia i wpisz kubectl version --clientpolecenie . Upewnij się, że wersja klienta kubectl ma co najmniej v1.24.0wartość . Aby uzyskać instrukcje dotyczące instalacji, zobacz kubectl.

Opcjonalne pierwsze kroki

Jeśli nie masz jeszcze grupy Microsoft Entra zawierającej członków, możesz utworzyć grupę i dodać członków, aby móc postępować zgodnie z instrukcjami w tym artykule.

Aby zademonstrować pracę z identyfikatorem Entra firmy Microsoft i kontrolą RBAC platformy Kubernetes, możesz utworzyć grupę Entra firmy Microsoft dla deweloperów aplikacji, która może służyć do pokazania, jak kontrola dostępu kubernetes RBAC i identyfikator firmy Microsoft Entra do zasobów klastra. W środowiskach produkcyjnych można używać istniejących użytkowników i grup w dzierżawie firmy Microsoft Entra.

Tworzenie grupy demonstracyjnej w usłudze Microsoft Entra ID

Najpierw utwórz grupę w identyfikatorze Entra firmy Microsoft w dzierżawie dla deweloperów aplikacji przy użyciu az ad group create polecenia . W poniższym przykładzie zostanie wyświetlony monit o zalogowanie się do dzierżawy platformy Azure, a następnie utworzenie grupy o nazwie appdev:

az login
az ad group create --display-name appdev --mail-nickname appdev

Dodawanie użytkowników do grupy

Za pomocą przykładowej grupy utworzonej w usłudze Microsoft Entra ID dla deweloperów aplikacji dodaj użytkownika do appdev grupy. To konto użytkownika służy do logowania się do klastra usługi AKS i testowania integracji RBAC platformy Kubernetes.

Dodaj użytkownika do grupy appdev utworzonej w poprzedniej sekcji przy użyciu az ad group member add polecenia . Jeśli opuścisz sesję, połącz się ponownie z platformą Azure przy użyciu polecenia az login.

$AKSDEV_ID = az ad user create --display-name <name> --password <strongpassword> --user-principal-name <name>@contoso.onmicrosoft.com
az ad group member add --group appdev --member-id $AKSDEV_ID

Tworzenie niestandardowego powiązania roli RBAC platformy Kubernetes w zasobie klastra usługi AKS dla grupy Microsoft Entra

Skonfiguruj klaster usługi AKS, aby zezwolić grupie Firmy Microsoft na dostęp do klastra. Jeśli chcesz dodać grupę i użytkowników, zobacz Tworzenie grup demonstracyjnych w identyfikatorze Entra firmy Microsoft.

1. Użyj polecenia , az aksarc get-credentials aby uzyskać poświadczenia administratora klastra:

   az aksarc get-credentials --name "sample-aksarccluster" --resource-group "sample-rg" --admin
   

2. Utwórz przestrzeń nazw w klastrze Kubernetes przy użyciu kubectl create namespace polecenia . Poniższy przykład tworzy przestrzeń nazw o nazwie dev:

   kubectl create namespace dev
   

Na platformie Kubernetes role definiują uprawnienia do udzielania, a roleBindings stosują uprawnienia do żądanych użytkowników lub grup. Te przypisania można zastosować do danej przestrzeni nazw lub w całym klastrze. Aby uzyskać więcej informacji, zobacz Using Kubernetes RBAC authorization (Używanie autoryzacji RBAC platformy Kubernetes).

Utwórz rolę dla przestrzeni nazw deweloperów. Ta rola udziela pełnych uprawnień do przestrzeni nazw. W środowiskach produkcyjnych możesz określić bardziej szczegółowe uprawnienia dla różnych użytkowników lub grup.

1. Utwórz plik o nazwie role-dev-namespace.yaml i skopiuj/wklej następujący manifest YAML :

   kind: Role
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: dev-user-full-access
     namespace: dev
   rules:
   - apiGroups: ["", "extensions", "apps"]
     resources: ["*"]
     verbs: ["*"]
   - apiGroups: ["batch"]
     resources:
     - jobs
     - cronjobs
     verbs: ["*"]
   

2. Utwórz rolę przy użyciu kubectl apply polecenia i określ nazwę pliku manifestu YAML:

   kubectl apply -f role-dev-namespace.yaml
   

3. Pobierz identyfikator zasobu dla grupy appdev przy użyciu az ad group show polecenia . Ta grupa jest ustawiana jako temat funkcji RoleBinding w następnym kroku:

   az ad group show --group appdev --query objectId -o tsv
   

   Polecenie az ad group show zwraca wartość używaną jako groupObjectId:

   38E5FA30-XXXX-4895-9A00-050712E3673A
   

4. Utwórz plik o nazwie rolebinding-dev-namespace.yaml i skopiuj/wklej następujący manifest YAML. Ustanawiasz powiązanie roli, które umożliwia grupie appdev używanie role-dev-namespace roli na potrzeby dostępu do przestrzeni nazw. W ostatnim wierszu zastąp element groupObjectId identyfikatorem obiektu grupy utworzonym az ad group show przez polecenie :

   kind: RoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: dev-user-access
     namespace: dev
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: dev-user-full-access
   subjects:
   - kind: Group
     namespace: dev
     name: groupObjectId
   

   Napiwek

   Jeśli chcesz utworzyć element RoleBinding dla pojedynczego użytkownika, określ kind: User i zastąp groupObjectId ciąg główną nazwą użytkownika (UPN) w przykładzie.

5. Utwórz element RoleBinding przy użyciu kubectl apply polecenia i określ nazwę pliku manifestu YAML:

   kubectl apply -f rolebinding-dev-namespace.yaml
   

   rolebinding.rbac.authorization.k8s.io/dev-user-access created
   

Używanie wbudowanych ról RBAC platformy Kubernetes dla zasobu klastra usługi AKS

Platforma Kubernetes udostępnia również wbudowane role dostępne dla użytkowników. Te wbudowane role obejmują:

• Role administratora (administrator klastra)
• Role przeznaczone do udzielenia dla całego klastra przy użyciu metody ClusterRoleBindings
• Role przeznaczone do udzielenia w określonych przestrzeniach nazw przy użyciu funkcji RoleBindings (administrator, edycja, widok)

Aby uzyskać więcej informacji na temat wbudowanych ról RBAC platformy Kubernetes, zobacz Role oparte na rolach użytkowników w usłudze Kubernetes RBAC.

Role dostępne dla użytkowników

Domyślny klasterRole	Domyślny klasterRoleBinding	opis
administrator klastra	system:masters group	Umożliwia dostęp administratora do wykonywania dowolnej akcji na dowolnym zasobie. W przypadku użycia w klastrze ClusterRoleBinding ta rola zapewnia pełną kontrolę nad każdym zasobem w klastrze i we wszystkich przestrzeniach nazw. W przypadku użycia w usłudze RoleBinding zapewnia pełną kontrolę nad każdym zasobem w przestrzeni nazw powiązania roli, w tym nad samą przestrzenią nazw.
administrator	Brak	Zezwala na dostęp administratora, który ma być udzielany w przestrzeni nazw przy użyciu powiązania roli. Jeśli jest używany w powiązaniu roli, 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. Ta rola nie zezwala również na dostęp do zapisu do punktów końcowych w klastrach utworzonych przy użyciu platformy Kubernetes w wersji 1.22 lub nowszej. Aby uzyskać więcej informacji, zobacz Write Access for Endpoints (Dostęp do zapisu dla punktów końcowych).
Edytuj…	Brak	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 dowolnego konta usługi w przestrzeni nazw, dzięki czemu może służyć do uzyskiwania poziomów dostępu interfejsu API dowolnego konta usługi w przestrzeni nazw. Ta rola nie zezwala również na dostęp do zapisu do punktów końcowych w klastrach utworzonych przy użyciu platformy Kubernetes w wersji 1.22 lub nowszej. Aby uzyskać więcej informacji, zobacz Write Access for Endpoints (Dostęp do zapisu dla punktów końcowych).
wyświetl	Brak	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 wpisów tajnych, ponieważ odczytywanie zawartości wpisów tajnych umożliwia dostęp do poświadczeń usługi ServiceAccount w przestrzeni nazw, co umożliwi dostęp do interfejsu API jako dowolny element ServiceAccount w przestrzeni nazw (forma eskalacji uprawnień).

Używanie wbudowanej roli RBAC platformy Kubernetes z identyfikatorem Entra firmy Microsoft

Aby użyć wbudowanej roli RBAC platformy Kubernetes z identyfikatorem Entra firmy Microsoft, wykonaj następujące kroki:

1. Zastosuj wbudowaną view rolę RBAC platformy Kubernetes w grupie Microsoft Entra:

   kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --group=<Azure AD group object ID>
   

2. Zastosuj wbudowaną view rolę RBAC platformy Kubernetes dla każdego z użytkowników firmy Microsoft Entra:

   kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --user=<Azure AD user object ID>
   

Praca z zasobami klastra przy użyciu tożsamości firmy Microsoft

Teraz przetestuj oczekiwane uprawnienia podczas tworzenia zasobów i zarządzania nimi w klastrze Kubernetes. W tych przykładach planujesz i wyświetlasz zasobniki w przypisanej przestrzeni nazw użytkownika. Następnie spróbujesz zaplanować i wyświetlić zasobniki poza przypisaną przestrzenią nazw.

1. Zaloguj się do platformy Azure przy użyciu konta użytkownika przekazanego $AKSDEV_ID jako dane wejściowe do az ad group member add polecenia . Uruchom polecenie , az connectedk8s proxy aby otworzyć kanał w klastrze:

   az connectedk8s proxy --name "sample-aksarccluster" --resource-group "sample-rg"
   

2. Po ustanowieniu kanału proxy otwórz kolejną sesję i zaplanuj zasobnik NGINX przy użyciu kubectl run polecenia w przestrzeni nazw deweloperów:

   kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
   

   Po pomyślnym zaplanowaniu serwera NGINX zobaczysz następujące dane wyjściowe:

   pod/nginx-dev created
   

3. Teraz użyj kubectl get pods polecenia , aby wyświetlić zasobniki w dev przestrzeni nazw:

   kubectl get pods --namespace dev
   

   Po pomyślnym uruchomieniu serwera NGINX powinny zostać wyświetlone następujące dane wyjściowe:

   NAME        READY   STATUS    RESTARTS   AGE
   nginx-dev   1/1     Running   0          4m
   

Tworzenie i wyświetlanie zasobów klastra poza przypisaną przestrzenią nazw

Aby spróbować wyświetlić zasobniki poza przestrzenią nazw deweloperów , użyj kubectl get pods polecenia z flagą --all-namespaces :

kubectl get pods --all-namespaces

Członkostwo użytkownika w grupie nie ma roli Kubernetes, która zezwala na tę akcję. Bez uprawnień polecenie generuje błąd:

Error from server (Forbidden): pods is forbidden: User cannot list resource "pods" in API group "" at the cluster scope

Następne kroki

• Kontrola dostępu oparta na rolach platformy Azure (Azure RBAC)