Kontrola dostępu przy użyciu kontroli dostępu Tożsamość Microsoft Entra i kontroli dostępu opartej na rolach platformy Kubernetes w usłudze AKS włączonej przez usługę Azure Arc

  • Artykuł

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

Azure Kubernetes Service (AKS) można skonfigurować do używania Tożsamość Microsoft Entra na potrzeby uwierzytelniania użytkowników. W tej konfiguracji zalogujesz się do klastra Kubernetes przy użyciu tokenu uwierzytelniania Microsoft Entra. Po uwierzytelnieniu możesz użyć wbudowanej kontroli dostępu opartej na rolach platformy Kubernetes (Kubernetes RBAC), aby zarządzać 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. Grupę demonstracyjną i użytkowników utworzysz w Tożsamość Microsoft Entra. Następnie utworzysz role i powiązania ról w klastrze, aby udzielić odpowiednich uprawnień do tworzenia i wyświetlania zasobów.

Wymagania wstępne

Przed skonfigurowaniem kontroli dostępu opartej na rolach platformy Kubernetes przy użyciu tożsamości Microsoft Entra potrzebne są następujące elementy:

  • Klaster Kubernetes utworzony w usłudze AKS Arc

    Potrzebujesz klastra Kubernetes utworzonego w usłudze AKS Arc. Jeśli musisz skonfigurować klaster, możesz znaleźć instrukcje dotyczące używania Windows Admin Center lub programu PowerShell do wdrażania usługi AKS.

  • 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 Azure Kubernetes Service w klastrze Azure Stack HCI z usługą Kubernetes z włączoną usługą Azure Arc).

  • Potrzebujesz dostępu do następujących narzędzi wiersza polecenia:

    • Interfejs wiersza polecenia platformy Azure i rozszerzenie connectedk8s

      Interfejs wiersza polecenia platformy Azure to zestaw poleceń służących 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 należy zainstalować rozszerzenie connectedk8s , aby otworzyć kanał w klastrze Kubernetes.

      Aby uzyskać instrukcje dotyczące instalacji, zobacz Jak zainstalować interfejs wiersza polecenia platformy Azure.

    • 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 narzędzie wiersza polecenia i wpisz: kubectl version --client. Upewnij się, że wersja klienta kubectl to co najmniej v1.24.0.

      Aby uzyskać instrukcje dotyczące instalacji, zobacz kubectl.

    • Program PowerShell i moduł programu PowerShell AksHci

      Program PowerShell to wieloplatformowe rozwiązanie do automatyzacji zadań składające się z powłoki wiersza polecenia, języka skryptów i struktury zarządzania konfiguracją. Jeśli zainstalowano usługę AKS Arc, masz dostęp do modułu programu PowerShell usługi AksHci.

Opcjonalne pierwsze kroki

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

Aby zademonstrować pracę z kontrolą dostępu opartą na rolach Tożsamość Microsoft Entra i Kubernetes, możesz utworzyć grupę Microsoft Entra dla deweloperów aplikacji, która może służyć do pokazywania sposobu kontroli dostępu na podstawie ról platformy Kubernetes i Tożsamość Microsoft Entra kontroli dostępu do zasobów klastra. W środowiskach produkcyjnych można używać istniejących użytkowników i grup w ramach dzierżawy Microsoft Entra.

Twórca grupę demonstracyjną w Tożsamość Microsoft Entra

Najpierw utwórz grupę w Tożsamość Microsoft Entra w dzierżawie dla deweloperów aplikacji za pomocą polecenia az ad group create. W poniższym przykładzie zalogowano się do dzierżawy platformy Azure, a następnie utworzono grupę o nazwie appdev:

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

Dodawanie użytkowników do grupy

W przypadku grupy przykładowej utworzonej w Tożsamość Microsoft Entra dla naszych deweloperów aplikacji dodajmy użytkownika do appdev grupy. Użyjesz tego konta użytkownika, aby zalogować się do klastra usługi AKS i przetestować integrację kontroli dostępu opartej na rolach platformy Kubernetes.

Dodaj użytkownika do grupy appdev utworzonej w poprzedniej sekcji przy użyciu polecenia az ad group member add . Jeśli zakończ sesję, ponownie połącz się 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

Twórca niestandardowe powiązanie roli RBAC platformy Kubernetes w zasobie klastra usługi AKS dla grupy Microsoft Entra

Skonfiguruj klaster usługi AKS, aby zezwolić grupie Microsoft Entra na dostęp do klastra. Jeśli chcesz dodać grupę i użytkowników, zobacz Twórca grupy demonstracyjne w Tożsamość Microsoft Entra.

  1. Pobierz poświadczenia administratora klastra przy użyciu polecenia Get-AksHciCredential :

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

  2. Twórca przestrzeni nazw w klastrze Kubernetes za pomocą polecenia kubectl create namespace. Poniższy przykład tworzy przestrzeń nazw o nazwie dev:

    kubectl create namespace dev

    W usłudze 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).

    Twórca 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. Twórca pliku o nazwie role-dev-namespace.yaml i 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. Twórca rolę przy użyciu polecenia kubectl apply i określ nazwę pliku manifestu YAML:

    kubectl apply -f role-dev-namespace.yaml

  5. Pobierz identyfikator zasobu dla grupy appdev przy użyciu polecenia az ad group show . 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ść, której użyjesz jako groupObjectId:

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

  6. Twórca pliku o nazwie rolebinding-dev-namespace.yaml i wklej następujący manifest YAML. Ustanawiasz powiązanie roli, które umożliwia grupie appdev używanie role-dev-namespace roli do uzyskiwania dostępu do przestrzeni nazw. W ostatnim wierszu zastąp ciąg 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

    Porada

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

  7. Twórca roleBinding przy użyciu polecenia kubectl apply 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 w całym klastrze przy użyciu klasterRoleBindings
  • Role przeznaczone do udzielenia w określonych przestrzeniach nazw przy użyciu funkcji RoleBindings (administrator, edycja, widok)

Aby dowiedzieć się więcej o wbudowanych rolach RBAC platformy Kubernetes, zobacz Role kontroli dostępu opartej na rolach platformy Kubernetes

Role dostępne dla użytkowników

Domyślny klasterRole Domyślny klasterRoleBinding Opis
administrator klastra system:masters group Umożliwia dostęp superu użytkownika do wykonywania dowolnej akcji w 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 zostać przyznany w przestrzeni nazw przy użyciu powiązania roli. W przypadku użycia 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 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 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 Dostęp do zapisu dla punktów końcowych.
widok 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 dowolne konto usługi w przestrzeni nazw (forma eskalacji uprawnień).

Używanie wbudowanej roli RBAC platformy Kubernetes z Tożsamość Microsoft Entra

Aby użyć wbudowanej roli RBAC platformy Kubernetes z Tożsamość Microsoft Entra, wykonaj następujące czynności:

  1. Zastosuj wbudowaną view rolę RBAC platformy Kubernetes do grupy 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 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 Microsoft Entra

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 przekazanego jako dane wejściowe do az ad group member add polecenia. 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 polecenia kubectl run 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 zostaną wyświetlone następujące dane wyjściowe:

    pod/nginx-dev created

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

    kubectl get pods --namespace dev

    Po pomyślnym uruchomieniu serwera NGINX są widoczne następujące dane wyjściowe:

    $ kubectl get pods --namespace dev

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

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

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

kubectl get pods --all-namespaces

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

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

Następne kroki