Udostępnij za pośrednictwem

Kontrola dostępu przy użyciu identyfikatora Entra firmy Microsoft i kontroli dostępu opartej na rolach platformy Kubernetes dla systemu Windows Server

  • Artykuł

Dotyczy: usługa AKS w usłudze Azure Stack HCI 22H2, AKS w systemie Windows Server

Usługę Azure Kubernetes Service (AKS) można skonfigurować do używania identyfikatora Entra firmy Microsoft do uwierzytelniania użytkowników. 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 Arc. 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 potrzebne są następujące wymagania wstępne:

  • Klaster Kubernetes utworzony w usłudze AKS Arc. Jeśli musisz skonfigurować klaster, zapoznaj się z instrukcjami dotyczącymi wdrażania usługi AKS przy użyciu centrum administracyjnego systemu Windows lub programu PowerShell .
  • Połączenie usługi Azure Arc. Musisz mieć połączenie usługi Azure Arc z klastrem Kubernetes. Aby uzyskać informacje na temat włączania usługi Azure Arc, zobacz Connect an Azure Kubernetes Service on Azure Stack HCI cluster to Azure Arc-enabled Kubernetes (Łączenie usługi Azure Kubernetes z klastrem Azure Stack HCI z włączoną usługą Azure Arc).
  • Potrzebny jest dostęp do następujących narzędzi wiersza polecenia:
    • Interfejs wiersza polecenia platformy Azure i rozszerzenie connectedk8s. Interfejs wiersza polecenia platformy Azure to zestaw poleceń używanych do tworzenia zasobów platformy Azure i zarządzania nimi. Aby sprawdzić, czy masz interfejs wiersza polecenia platformy Azure, otwórz narzędzie wiersza polecenia i wpisz: az -v. Ponadto zainstaluj rozszerzenie connectedk8s, aby otworzyć kanał w klastrze Kubernetes. Aby uzyskać instrukcje dotyczące instalacji, zobacz How to install Azure CLI (Jak zainstalować interfejs wiersza polecenia platformy Azure).
    • Kubectl. To narzędzie wiersza polecenia kubernetes umożliwia uruchamianie poleceń przeznaczonych dla klastrów Kubernetes. Aby sprawdzić, czy zainstalowano narzędzie kubectl, otwórz wiersz polecenia i wpisz: kubectl version --client. Upewnij się, że wersja klienta kubectl jest co najmniej wersja 1.24.0. Aby uzyskać instrukcje dotyczące instalacji, zobacz kubectl.
    • Program PowerShell i moduł programu PowerShell AksHci. Program PowerShell to międzyplatformowe rozwiązanie do automatyzacji zadań składające się z powłoki wiersza polecenia, języka skryptowego i platformy zarządzania konfiguracją. Jeśli zainstalowano usługę AKS Arc, masz dostęp do modułu AksHci programu PowerShell.
    • Aby uzyskać dostęp do klastra Kubernetes z dowolnego miejsca za pomocą trybu serwera proxy przy użyciu az connectedk8s proxy polecenia, musisz mieć uprawnienie Microsoft.Kubernetes/connectedClusters/listClusterUserCredential/action, które jest uwzględnione w roli użytkownika klastra Kubernetes z obsługą usługi Azure Arc. W międzyczasie należy sprawdzić, czy agenci i maszyna wykonująca proces dołączania spełniają wymagania sieciowe w ramach wymagań sieciowych platformy Kubernetes z obsługą usługi Azure Arc.

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. Pobierz poświadczenia administratora klastra przy użyciu Get-AksHciCredential polecenia :

    Get-AksHciCredential -name <name-of-your-cluster>

  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.

  3. 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: ["*"]

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

    kubectl apply -f role-dev-namespace.yaml

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

  6. 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 główną nazwą użytkownika (UPN) w przykładzie.

  7. 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 identyfikatorów Entra 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 $AKSDEV_ID konta użytkownika określonego jako dane wejściowe polecenia az ad group member add . Uruchom polecenie , az connectedk8s proxy aby otworzyć kanał w klastrze:

    az connectedk8s proxy -n <cluster-name> -g <resource-group>

  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 powinny zostać wyświetlone 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