Używanie kontroli dostępu opartej na rolach platformy Kubernetes z identyfikatorem Entra firmy Microsoft w usłudze Azure Kubernetes Service

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 usługi AKS 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 pokazano, w jaki sposób wykonać następujące czynności:

• Kontrolowanie dostępu przy użyciu kontroli dostępu opartej na rolach platformy Kubernetes w klastrze usługi AKS na podstawie członkostwa w grupie Microsoft Entra.
• Utwórz przykładowe grupy i użytkowników w identyfikatorze Entra firmy Microsoft.
• Utwórz role i roleBindings w klastrze usługi AKS, aby udzielić odpowiednich uprawnień do tworzenia i wyświetlania zasobów.

Zanim rozpoczniesz

• Masz istniejący klaster usługi AKS z włączoną integracją firmy Microsoft Entra. Jeśli potrzebujesz klastra usługi AKS z tą konfiguracją, zobacz Integrowanie identyfikatora Entra firmy Microsoft z usługą AKS.
• Kontrola dostępu oparta na rolach platformy Kubernetes jest domyślnie włączona podczas tworzenia klastra usługi AKS. Aby uaktualnić klaster przy użyciu integracji z firmą Microsoft Entra i kontroli dostępu opartej na rolach platformy Kubernetes, włącz integrację firmy Microsoft z istniejącym klastrem usługi AKS.
• Upewnij się, że interfejs wiersza polecenia platformy Azure w wersji 2.0.61 lub nowszej jest zainstalowany i skonfigurowany. Uruchom polecenie az --version, aby dowiedzieć się, jaka wersja jest używana. Jeśli konieczna będzie instalacja lub uaktualnienie, zobacz Instalowanie interfejsu wiersza polecenia platformy Azure.
• W przypadku korzystania z programu Terraform zainstaluj program Terraform w wersji 2.99.0 lub nowszej.

Użyj witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure, aby sprawdzić, czy integracja usługi Microsoft Entra z kontrolą dostępu opartą na rolach platformy Kubernetes jest włączona.

Witryna Azure Portal

Aby sprawdzić, czy używasz witryny Azure Portal:

1. Zaloguj się do witryny Azure Portal i przejdź do zasobu klastra usługi AKS.
2. W menu usługi w obszarze Ustawienia wybierz pozycję Konfiguracja klastra.
3. W sekcji Uwierzytelnianie i autoryzacja sprawdź, czy wybrano opcję RBAC RBAC firmy Microsoft w usłudze Microsoft Entra.

Interfejs wiersza polecenia platformy Azure

Możesz sprawdzić przy użyciu polecenia interfejsu wiersza polecenia az aks show platformy Azure. Zastąp wartość myResourceGroup nazwą grupy zasobów hostująca zasób klastra usługi AKS i zastąp ciąg myAKSCluster rzeczywistą nazwą klastra usługi AKS.

az aks show --resource-group myResourceGroup --name myAKSCluster

Jeśli jest włączona, dane wyjściowe zawierają wartość parametru enableAzureRbac .false

Tworzenie grup demonstracyjnych w identyfikatorze Entra firmy Microsoft

W tym artykule utworzymy dwie role użytkownika, aby pokazać, jak kontrola dostępu na podstawie ról kubernetes i identyfikator entra firmy Microsoft kontrolują dostęp do zasobów klastra. Używane są następujące dwie przykładowe role:

• Deweloper aplikacji
  • Użytkownik o nazwie aksdev , który jest częścią grupy appdev .
• Inżynier niezawodności lokacji
  • Użytkownik o nazwie akssre , który jest częścią grupy opssre .

W środowiskach produkcyjnych można używać istniejących użytkowników i grup w dzierżawie firmy Microsoft Entra.

1. Najpierw pobierz identyfikator zasobu klastra usługi AKS przy użyciu az aks show polecenia . Następnie przypisz identyfikator zasobu do zmiennej o nazwie AKS_ID , aby można było odwoływać się do niego w innych poleceniach.

   AKS_ID=$(az aks show \
       --resource-group myResourceGroup \
       --name myAKSCluster \
       --query id -o tsv)
   

2. Utwórz pierwszą przykładowy grupę w identyfikatorze Entra firmy Microsoft dla deweloperów aplikacji przy użyciu az ad group create polecenia . Poniższy przykład tworzy grupę o nazwie appdev:

   APPDEV_ID=$(az ad group create --display-name appdev --mail-nickname appdev --query id -o tsv)
   

3. Utwórz przypisanie roli platformy Azure dla grupy appdev przy użyciu az role assignment create polecenia . To przypisanie umożliwia każdemu członkowi grupy kubectl interakcję z klastrem usługi AKS, udzielając im roli użytkownika klastra usługi Azure Kubernetes Service.

   az role assignment create \
     --assignee $APPDEV_ID \
     --role "Azure Kubernetes Service Cluster User Role" \
     --scope $AKS_ID
   

Napiwek

Jeśli wystąpi błąd, taki jak Principal 35bfec9328bd4d8d9b54dea6dac57b82 doesn't exist in the directory a5443dcd-cd0e-494d-a387-3039b419f0d5., zaczekaj kilka sekund na propagację identyfikatora obiektu grupy Microsoft Entra za pośrednictwem katalogu, a następnie spróbuj az role assignment create ponownie wykonać polecenie.

4. Utwórz drugą przykładową grupę dla środowisk SREs o nazwie opssre.

   OPSSRE_ID=$(az ad group create --display-name opssre --mail-nickname opssre --query id -o tsv)
   

5. Utwórz przypisanie roli platformy Azure, aby przyznać członkom grupy rolę użytkownika klastra usługi Azure Kubernetes Service.

   az role assignment create \
     --assignee $OPSSRE_ID \
     --role "Azure Kubernetes Service Cluster User Role" \
     --scope $AKS_ID
   

Tworzenie użytkowników demonstracyjnych w usłudze Microsoft Entra ID

Teraz, gdy mamy dwie przykładowe grupy utworzone w usłudze Microsoft Entra ID dla deweloperów aplikacji i środowiska SRE, utworzymy dwóch przykładowych użytkowników. Aby przetestować integrację RBAC platformy Kubernetes na końcu artykułu, zalogujesz się do klastra usługi AKS przy użyciu tych kont.

Ustawianie głównej nazwy użytkownika i hasła dla deweloperów aplikacji

Ustaw główną nazwę użytkownika (UPN) i hasło dla deweloperów aplikacji. Nazwa UPN musi zawierać zweryfikowaną nazwę domeny dzierżawy, na przykład aksdev@contoso.com.

Następujące polecenie wyświetla monit o nazwę UPN i ustawia ją na AAD_DEV_UPN , aby można było jej użyć w późniejszym poleceniu:

echo "Please enter the UPN for application developers: " && read AAD_DEV_UPN

Następujące polecenie wyświetla monit o hasło i ustawia je na AAD_DEV_PW do użycia w późniejszym poleceniu:

echo "Please enter the secure password for application developers: " && read AAD_DEV_PW

Tworzenie kont użytkowników

1. Utwórz pierwsze konto użytkownika w identyfikatorze az ad user create Entra firmy Microsoft przy użyciu polecenia . Poniższy przykład tworzy użytkownika o nazwie wyświetlanej AKS Dev oraz nazwy UPN i bezpiecznego hasła przy użyciu wartości w AAD_DEV_UPN i AAD_DEV_PW:

AKSDEV_ID=$(az ad user create \
  --display-name "AKS Dev" \
  --user-principal-name $AAD_DEV_UPN \
  --password $AAD_DEV_PW \
  --query id -o tsv)

2. Dodaj użytkownika do grupy appdev utworzonej w poprzedniej sekcji przy użyciu az ad group member add polecenia .

az ad group member add --group appdev --member-id $AKSDEV_ID

3. Skonfiguruj nazwę UPN i hasło dla srEs. Nazwa UPN musi zawierać zweryfikowaną nazwę domeny dzierżawy, na przykład akssre@contoso.com. Następujące polecenie wyświetla monit o nazwę UPN i ustawia ją na AAD_SRE_UPN do użycia w późniejszym poleceniu:

echo "Please enter the UPN for SREs: " && read AAD_SRE_UPN

4. Następujące polecenie wyświetla monit o hasło i ustawia je na AAD_SRE_PW do użycia w późniejszym poleceniu:

echo "Please enter the secure password for SREs: " && read AAD_SRE_PW

5. Utwórz drugie konto użytkownika. W poniższym przykładzie zostanie utworzony użytkownik o nazwie wyświetlanej AKS SRE oraz nazwa UPN i bezpieczne hasło przy użyciu wartości w AAD_SRE_UPN i AAD_SRE_PW:

# Create a user for the SRE role
AKSSRE_ID=$(az ad user create \
  --display-name "AKS SRE" \
  --user-principal-name $AAD_SRE_UPN \
  --password $AAD_SRE_PW \
  --query id -o tsv)

# Add the user to the opssre Azure AD group
az ad group member add --group opssre --member-id $AKSSRE_ID

Tworzenie zasobów klastra usługi AKS dla deweloperów aplikacji

Mamy utworzone grupy, użytkowników i role platformy Azure firmy Microsoft. Teraz skonfigurujemy klaster usługi AKS, aby zezwolić tym różnym grupom na dostęp do określonych zasobów.

1. Pobierz poświadczenia administratora klastra az aks get-credentials przy użyciu polecenia . W jednej z poniższych sekcji uzyskasz poświadczenia zwykłego klastra użytkownika , aby zobaczyć w akcji przepływ uwierzytelniania entra firmy Microsoft.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --admin

2. Utwórz przestrzeń nazw w klastrze usługi AKS przy użyciu kubectl create namespace polecenia . W poniższym przykładzie zostanie utworzona nazwa przestrzeni nazw dev:

kubectl create namespace dev

Uwaga

Na platformie Kubernetes role definiują uprawnienia do udzielania, a roleBindings stosują je 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).

Jeśli użytkownik, dla którego przyznano powiązanie RBAC platformy Kubernetes, znajduje się w tej samej dzierżawie firmy Microsoft Entra, przypisz uprawnienia na podstawie nazwy UPN (userPrincipalName). Jeśli użytkownik znajduje się w innej dzierżawie firmy Microsoft Entra, zamiast tego wykonaj zapytanie o właściwość objectId i użyj jej.

3. Utwórz rolę dla przestrzeni nazw deweloperów, która przyznaje pełne uprawnienia do przestrzeni nazw. W środowiskach produkcyjnych można określić bardziej szczegółowe uprawnienia dla różnych użytkowników lub grup. Utwórz plik 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. 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 id -o tsv

6. Utwórz element RoleBinding dla grupy appdev , aby użyć wcześniej utworzonej roli na potrzeby dostępu do przestrzeni nazw. Utwórz plik o nazwie rolebinding-dev-namespace.yaml i wklej następujący manifest YAML. W ostatnim wierszu zastąp element groupObjectId danymi wyjściowymi identyfikatora obiektu grupy z poprzedniego polecenia.

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ć właściwość RoleBinding dla pojedynczego użytkownika, określ rodzaj: Użytkownik i zastąp element groupObjectId główną nazwą użytkownika (UPN) w powyższym 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

Tworzenie zasobów klastra usługi AKS dla srEs

Teraz powtórzmy poprzednie kroki, aby utworzyć przestrzeń nazw, rolę i powiązanie ról dla srEs.

1. Utwórz przestrzeń nazw dla sre przy użyciu kubectl create namespace polecenia .

kubectl create namespace sre

2. Utwórz plik o nazwie role-sre-namespace.yaml i wklej następujący manifest YAML:

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

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

kubectl apply -f role-sre-namespace.yaml

4. Pobierz identyfikator zasobu dla grupy opssre przy użyciu polecenia az ad group show .

az ad group show --group opssre --query id -o tsv

4. Utwórz element RoleBinding dla grupy opssre , aby użyć wcześniej utworzonej roli na potrzeby dostępu do przestrzeni nazw. Utwórz plik o nazwie rolebinding-sre-namespace.yaml i wklej następujący manifest YAML. W ostatnim wierszu zastąp element groupObjectId danymi wyjściowymi identyfikatora obiektu grupy z poprzedniego polecenia.

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

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

kubectl apply -f rolebinding-sre-namespace.yaml

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

Teraz przetestujemy, czy oczekiwane uprawnienia działają podczas tworzenia zasobów w klastrze usługi AKS i zarządzania nimi. W tych przykładach zaplanujemy i wyświetlimy zasobniki w przypisanej przestrzeni nazw użytkownika i spróbujemy zaplanować i wyświetlić zasobniki poza przypisaną przestrzenią nazw.

1. Zresetuj az aks get-credentials kontekst kubeconfig przy użyciu polecenia . W poprzedniej sekcji ustawisz kontekst przy użyciu poświadczeń administratora klastra. Administrator pomija monity logowania firmy Microsoft Entra. Bez parametru --admin jest stosowany kontekst użytkownika, który wymaga uwierzytelnienia wszystkich żądań przy użyciu identyfikatora Microsoft Entra.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing

2. Zaplanuj podstawowy 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

3. Wprowadź poświadczenia dla własnego appdev@contoso.com konta utworzonego na początku artykułu jako monit logowania. Po pomyślnym zalogowaniu token konta jest buforowany dla przyszłych kubectl poleceń. Serwer NGINX został pomyślnie zaplanowany, jak pokazano w następujących przykładowych danych wyjściowych:

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

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code B24ZD6FP8 to authenticate.

pod/nginx-dev created

4. Użyj polecenia , kubectl get pods aby wyświetlić zasobniki w przestrzeni nazw deweloperów.

kubectl get pods --namespace dev

5. Upewnij się, że stan zasobnika NGINX to Uruchomiono. Dane wyjściowe będą wyglądać podobnie do następujących danych wyjściowych:

$ kubectl get pods --namespace dev

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

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

Spróbuj wyświetlić zasobniki poza przestrzenią nazw deweloperów . kubectl get pods Ponownie użyj polecenia , tym razem, aby wyświetlić polecenie --all-namespaces.

kubectl get pods --all-namespaces

Członkostwo użytkownika w grupie nie ma roli Kubernetes, która zezwala na tę akcję, jak pokazano w poniższych przykładowych danych wyjściowych:

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

W ten sam sposób spróbuj zaplanować zasobnik w innej przestrzeni nazw, takiej jak przestrzeń nazw sre . Członkostwo użytkownika w grupie nie jest zgodne z rolą platformy Kubernetes i funkcją RoleBinding w celu udzielenia tych uprawnień, jak pokazano w następujących przykładowych danych wyjściowych:

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

Error from server (Forbidden): pods is forbidden: User "aksdev@contoso.com" cannot create resource "pods" in API group "" in the namespace "sre"

Testowanie dostępu SRE do zasobów klastra usługi AKS

Aby potwierdzić, że nasze członkostwo w grupie Microsoft Entra i kontrola RBAC platformy Kubernetes działają poprawnie między różnymi użytkownikami i grupami, spróbuj wykonać poprzednie polecenia po zalogowaniu się jako użytkownik opssre .

1. Zresetuj kontekst kubeconfig przy użyciu az aks get-credentials polecenia , które czyści wcześniej buforowany token uwierzytelniania dla użytkownika aksdev .

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing

2. Spróbuj zaplanować i wyświetlić zasobniki w przypisanej przestrzeni nazw sre . Po wyświetleniu monitu zaloguj się przy użyciu własnych opssre@contoso.com poświadczeń utworzonych na początku artykułu.

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

Jak pokazano w poniższych przykładowych danych wyjściowych, można pomyślnie utworzyć i wyświetlić zasobniki:

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

3. To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code BM4RHP3FD to authenticate.

pod/nginx-sre created

$ kubectl get pods --namespace sre

NAME        READY   STATUS    RESTARTS   AGE
nginx-sre   1/1     Running   0

4. Spróbuj wyświetlić lub zaplanować zasobniki poza przypisaną przestrzenią nazw SRE.

kubectl get pods --all-namespaces
kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev

Te kubectl polecenia kończą się niepowodzeniem, jak pokazano w poniższych przykładowych danych wyjściowych. Członkostwo użytkownika w grupach i Role i RoleBindings platformy Kubernetes nie udzielają uprawnień do tworzenia zasobów ani zarządzania nimi w innych przestrzeniach nazw.

$ kubectl get pods --all-namespaces
Error from server (Forbidden): pods is forbidden: User "akssre@contoso.com" cannot list pods at the cluster scope

$ kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
Error from server (Forbidden): pods is forbidden: User "akssre@contoso.com" cannot create pods in the namespace "dev"

Czyszczenie zasobów

W tym artykule utworzono zasoby w klastrze usługi AKS oraz użytkownikach i grupach w usłudze Microsoft Entra ID. Aby wyczyścić wszystkie zasoby, uruchom następujące polecenia:

# Get the admin kubeconfig context to delete the necessary cluster resources.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --admin

# Delete the dev and sre namespaces. This also deletes the pods, Roles, and RoleBindings.

kubectl delete namespace dev
kubectl delete namespace sre

# Delete the Azure AD user accounts for aksdev and akssre.

az ad user delete --upn-or-object-id $AKSDEV_ID
az ad user delete --upn-or-object-id $AKSSRE_ID

# Delete the Azure AD groups for appdev and opssre. This also deletes the Azure role assignments.

az ad group delete --group appdev
az ad group delete --group opssre

Następne kroki

• Aby uzyskać więcej informacji na temat zabezpieczania klastrów Kubernetes, zobacz Opcje dostępu i tożsamości dla usługi AKS.

• Aby uzyskać najlepsze rozwiązania dotyczące tożsamości i kontroli zasobów, zobacz Najlepsze rozwiązania dotyczące uwierzytelniania i autoryzacji w usłudze AKS.