Op rollen gebaseerd toegangsbeheer van Kubernetes gebruiken met Microsoft Entra ID in Azure Kubernetes Service

Artikel
08/25/2024

Azure Kubernetes Service (AKS) kan worden geconfigureerd voor het gebruik van Microsoft Entra-id voor gebruikersverificatie. In deze configuratie meldt u zich aan bij een AKS-cluster met behulp van een Microsoft Entra-verificatietoken. Zodra de verificatie is uitgevoerd, kunt u het ingebouwde op rollen gebaseerde toegangsbeheer van Kubernetes (Kubernetes RBAC) gebruiken om de toegang tot naamruimten en clusterbronnen te beheren op basis van de identiteit of groepslidmaatschap van een gebruiker.

Dit artikel laat het volgende zien:

Toegang beheren met Kubernetes RBAC in een AKS-cluster op basis van microsoft Entra-groepslidmaatschap.
Maak voorbeeldgroepen en gebruikers in Microsoft Entra-id.
Maak Rollen en RoleBindings in een AKS-cluster om de juiste machtigingen te verlenen voor het maken en weergeven van resources.

Voordat u begint

U hebt een bestaand AKS-cluster waarvoor Microsoft Entra-integratie is ingeschakeld. Als u een AKS-cluster met deze configuratie nodig hebt, raadpleegt u Microsoft Entra-id integreren met AKS.
Kubernetes RBAC is standaard ingeschakeld tijdens het maken van een AKS-cluster. Als u uw cluster wilt upgraden met Microsoft Entra-integratie en Kubernetes RBAC, schakelt u Microsoft Entra-integratie in op uw bestaande AKS-cluster.
Zorg ervoor dat Azure CLI versie 2.0.61 of hoger is geïnstalleerd en geconfigureerd. Voer az --version uit om de versie te bekijken. Als u Azure CLI 2.0 wilt installeren of upgraden, raadpleegt u Azure CLI 2.0 installeren.
Als u Terraform gebruikt, installeert u Terraform versie 2.99.0 of hoger.

Gebruik Azure Portal of Azure CLI om te controleren of Microsoft Entra-integratie met Kubernetes RBAC is ingeschakeld.

Azure-portal
Azure-CLI

Ga als volgende te werk om te controleren met behulp van Azure Portal:

Meld u aan bij Azure Portal en navigeer naar uw AKS-clusterresource.
Selecteer clusterconfiguratie in het servicemenu onder Instellingen.
Controleer in de sectie Verificatie en autorisatie of microsoft Entra-verificatie met kubernetes RBAC is geselecteerd.

U kunt dit controleren met behulp van de Azure CLI-opdracht az aks show . Vervang de waarde myResourceGroup door de naam van de resourcegroep die als host fungeert voor de AKS-clusterresource en vervang myAKSCluster door de werkelijke naam van uw AKS-cluster.

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

Als deze optie is ingeschakeld, wordt in de uitvoer de waarde voor enableAzureRbac falseopgegeven.

Demogroepen maken in Microsoft Entra-id

In dit artikel maken we twee gebruikersrollen om te laten zien hoe Kubernetes RBAC en Microsoft Entra ID-toegang tot clusterbronnen beheren. De volgende twee voorbeeldrollen worden gebruikt:

Toepassingsontwikkelaar
- Een gebruiker met de naam aksdev die deel uitmaakt van de appdev-groep .
Sitebetrouwbaarheidstechnicus
- Een gebruiker met de naam akssre die deel uitmaakt van de opssre-groep .

In productieomgevingen kunt u bestaande gebruikers en groepen in een Microsoft Entra-tenant gebruiken.

Haal eerst de resource-id van uw AKS-cluster op met behulp van de az aks show opdracht. Wijs vervolgens de resource-id toe aan een variabele met de naam AKS_ID , zodat er in andere opdrachten naar kan worden verwezen.
```
AKS_ID=$(az aks show \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --query id -o tsv)
```
Maak de eerste voorbeeldgroep in Microsoft Entra-id voor de toepassingsontwikkelaars met behulp van de az ad group create opdracht. In het volgende voorbeeld wordt een groep met de naam appdev gemaakt:
```
APPDEV_ID=$(az ad group create --display-name appdev --mail-nickname appdev --query id -o tsv)
```
Maak een Azure-roltoewijzing voor de appdev-groep met behulp van de az role assignment create opdracht. Met deze toewijzing kan elk lid van de groep kubectl communiceren met een AKS-cluster door hen de gebruikersrol Azure Kubernetes Service-cluster te verlenen.
```
az role assignment create \
  --assignee $APPDEV_ID \
  --role "Azure Kubernetes Service Cluster User Role" \
  --scope $AKS_ID
```

Tip

Als er een fout wordt weergegeven, Principal 35bfec9328bd4d8d9b54dea6dac57b82 doesn't exist in the directory a5443dcd-cd0e-494d-a387-3039b419f0d5.wacht u een paar seconden totdat de object-id van de Microsoft Entra-groep is doorgegeven via de map en probeert u de az role assignment create opdracht opnieuw.

Maak een tweede voorbeeldgroep voor SRE's met de naam opssre.

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

Maak een Azure-roltoewijzing om leden van de groep de gebruikersrol Azure Kubernetes Service-cluster te verlenen.

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

Demogebruikers maken in Microsoft Entra ID

Nu we twee voorbeeldgroepen hebben gemaakt in Microsoft Entra ID voor onze toepassingsontwikkelaars en SRE's, maken we twee voorbeeldgebruikers. Als u de Kubernetes RBAC-integratie aan het einde van het artikel wilt testen, meldt u zich met deze accounts aan bij het AKS-cluster.

De principal-naam en het wachtwoord van de gebruiker instellen voor toepassingsontwikkelaars

Stel de UPN (User Principal Name) en het wachtwoord voor de ontwikkelaars van de toepassing in. De UPN moet bijvoorbeeld aksdev@contoso.comde geverifieerde domeinnaam van uw tenant bevatten.

De volgende opdracht vraagt u om de UPN en stelt deze in op AAD_DEV_UPN zodat deze in een latere opdracht kan worden gebruikt:

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

De volgende opdracht vraagt u om het wachtwoord en stelt dit in op AAD_DEV_PW voor gebruik in een latere opdracht:

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

De gebruikersaccounts maken

Maak het eerste gebruikersaccount in Microsoft Entra ID met behulp van de az ad user create opdracht. In het volgende voorbeeld wordt een gebruiker gemaakt met de weergavenaam AKS Dev en de UPN en het beveiligde wachtwoord met behulp van de waarden in AAD_DEV_UPN en 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)

Voeg de gebruiker toe aan de appdev-groep die in de vorige sectie is gemaakt met behulp van de az ad group member add opdracht.

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

Stel de UPN en het wachtwoord voor SRE's in. De UPN moet bijvoorbeeld akssre@contoso.comde geverifieerde domeinnaam van uw tenant bevatten. De volgende opdracht vraagt u om de UPN en stelt deze in op AAD_SRE_UPN voor gebruik in een latere opdracht:

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

De volgende opdracht vraagt u om het wachtwoord en stelt dit in op AAD_SRE_PW voor gebruik in een latere opdracht:

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

Maak een tweede gebruikersaccount. In het volgende voorbeeld wordt een gebruiker met de weergavenaam AKS SRE en de UPN en het wachtwoord beveiligd met behulp van de waarden in AAD_SRE_UPN en 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

AKS-clusterbronnen maken voor app-dev's

We hebben onze Microsoft Entra-groepen, gebruikers en Azure-roltoewijzingen gemaakt. Nu gaan we het AKS-cluster zo configureren dat deze verschillende groepen toegang hebben tot specifieke resources.

Haal de referenties van de clusterbeheerder op met behulp van de az aks get-credentials opdracht. In een van de volgende secties krijgt u de reguliere gebruikersclusterreferenties om de Microsoft Entra-verificatiestroom in actie te zien.

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

Maak een naamruimte in het AKS-cluster met behulp van de kubectl create namespace opdracht. In het volgende voorbeeld wordt een naamruimtenaam dev gemaakt:

kubectl create namespace dev

Notitie

In Kubernetes definiëren rollen de machtigingen die moeten worden verleend, en RoleBindings passen ze toe op de gewenste gebruikers of groepen. Deze toewijzingen kunnen worden toegepast op een bepaalde naamruimte of in het hele cluster. Zie Kubernetes RBAC-autorisatie gebruiken voor meer informatie.

Als de gebruiker waarvoor u de Kubernetes RBAC-binding verleent zich in dezelfde Microsoft Entra-tenant bevindt, wijst u machtigingen toe op basis van de UPN (userPrincipalName). Als de gebruiker zich in een andere Microsoft Entra-tenant bevindt, zoekt en gebruikt u in plaats daarvan de eigenschap objectId .

Maak een rol voor de ontwikkelnaamruimte , die volledige machtigingen verleent aan de naamruimte. In productieomgevingen kunt u gedetailleerdere machtigingen opgeven voor verschillende gebruikers of groepen. Maak een bestand met de naam role-dev-namespace.yaml en plak het volgende YAML-manifest:

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

Maak de rol met behulp van de kubectl apply opdracht en geef de bestandsnaam van uw YAML-manifest op.

kubectl apply -f role-dev-namespace.yaml

Haal de resource-id voor de appdev-groep op met behulp van de az ad group show opdracht. Deze groep wordt in de volgende stap ingesteld als het onderwerp van een RoleBinding.

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

Maak een RoleBinding voor de appdev-groep om de eerder gemaakte rol te gebruiken voor toegang tot naamruimten. Maak een bestand met de naam rolebinding-dev-namespace.yaml en plak het volgende YAML-manifest. Vervang op de laatste regel groupObjectId door de uitvoer van de groepsobject-id van de vorige opdracht.

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

Tip

Als u de RoleBinding voor één gebruiker wilt maken, geeft u het type op: Gebruiker en vervang groupObjectId door de UPN (User Principal Name) in het bovenstaande voorbeeld.

Maak de RoleBinding met behulp van de kubectl apply opdracht en geef de bestandsnaam van uw YAML-manifest op:

kubectl apply -f rolebinding-dev-namespace.yaml

De AKS-clusterresources voor SRE's maken

Nu herhalen we de vorige stappen om een naamruimte, rol en RoleBinding te maken voor de SRE's.

Maak een naamruimte voor sre met behulp van de kubectl create namespace opdracht.

kubectl create namespace sre

Maak een bestand met de naam role-sre-namespace.yaml en plak het volgende YAML-manifest:

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

Maak de rol met behulp van de kubectl apply opdracht en geef de bestandsnaam van uw YAML-manifest op.

kubectl apply -f role-sre-namespace.yaml

Haal de resource-id voor de opssre-groep op met behulp van de opdracht az ad group show .

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

Maak een RoleBinding voor de opssre-groep om de eerder gemaakte rol te gebruiken voor toegang tot naamruimten. Maak een bestand met de naam rolebinding-sre-namespace.yaml en plak het volgende YAML-manifest. Vervang op de laatste regel groupObjectId door de uitvoer van de groepsobject-id van de vorige opdracht.

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

Maak de RoleBinding met behulp van de kubectl apply opdracht en geef de bestandsnaam van uw YAML-manifest op.

kubectl apply -f rolebinding-sre-namespace.yaml

Interactie met clusterbronnen met Behulp van Microsoft Entra-identiteiten

Nu gaan we testen of de verwachte machtigingen werken wanneer u resources in een AKS-cluster maakt en beheert. In deze voorbeelden plannen en bekijken we pods in de toegewezen naamruimte van de gebruiker en proberen pods buiten de toegewezen naamruimte te plannen en weer te geven.

Stel de kubeconfig-context opnieuw in met behulp van de az aks get-credentials opdracht. In een vorige sectie stelt u de context in met behulp van de referenties van de clusterbeheerder. De gebruiker met beheerdersrechten omzeilt aanmeldingsprompts van Microsoft Entra. Zonder de --admin parameter wordt de gebruikerscontext toegepast waarvoor alle aanvragen moeten worden geverifieerd met behulp van Microsoft Entra-id.

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

Plan een eenvoudige NGINX-pod met behulp van de kubectl run opdracht in de dev-naamruimte .

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

Voer de referenties in voor uw eigen appdev@contoso.com account die aan het begin van het artikel zijn gemaakt als de aanmeldingsprompt. Zodra u bent aangemeld, wordt het accounttoken in de cache opgeslagen voor toekomstige kubectl opdrachten. De NGINX wordt gepland, zoals wordt weergegeven in de volgende voorbeelduitvoer:

$ 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

Gebruik de kubectl get pods opdracht om pods in de dev-naamruimte weer te geven.

kubectl get pods --namespace dev

Zorg ervoor dat de status van de NGINX-pod wordt uitgevoerd. De uitvoer ziet er ongeveer als volgt uit:

$ kubectl get pods --namespace dev

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

Clusterbronnen buiten de toegewezen naamruimte maken en weergeven

Probeer pods buiten de dev-naamruimte weer te geven. Gebruik de kubectl get pods opdracht opnieuw, deze keer om te zien --all-namespaces.

kubectl get pods --all-namespaces

Het groepslidmaatschap van de gebruiker heeft geen Kubernetes-rol die deze actie toestaat, zoals wordt weergegeven in de volgende voorbeelduitvoer:

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

Probeer op dezelfde manier een pod in een andere naamruimte te plannen, zoals de sre-naamruimte . Het groepslidmaatschap van de gebruiker komt niet overeen met een Kubernetes-rol en RoleBinding om deze machtigingen te verlenen, zoals wordt weergegeven in de volgende voorbeelduitvoer:

$ 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"

De SRE-toegang tot de AKS-clusterresources testen

Als u wilt controleren of ons Microsoft Entra-groepslidmaatschap en Kubernetes RBAC correct werken tussen verschillende gebruikers en groepen, probeert u de vorige opdrachten wanneer u bent aangemeld als de opsre-gebruiker .

Stel de kubeconfig-context opnieuw in met behulp van de az aks get-credentials opdracht waarmee het eerder in de cache opgeslagen verificatietoken voor de aksdev-gebruiker wordt gewist.

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

Probeer pods te plannen en weer te geven in de toegewezen sre-naamruimte . Meld u aan met uw eigen opssre@contoso.com referenties die zijn gemaakt aan het begin van het artikel wanneer u hierom wordt gevraagd.

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

Zoals wordt weergegeven in de volgende voorbeelduitvoer, kunt u de pods maken en weergeven:

$ 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

Probeer pods buiten de toegewezen SRE-naamruimte weer te geven of te plannen.

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

Deze kubectl opdrachten mislukken, zoals wordt weergegeven in de volgende voorbeelduitvoer. Het groepslidmaatschap van de gebruiker en de Kubernetes-rol en RoleBindings verlenen geen machtigingen voor het maken of beheren van resources in andere naamruimten.

$ 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"

Resources opschonen

In dit artikel hebt u resources gemaakt in het AKS-cluster en gebruikers en groepen in Microsoft Entra-id. Voer de volgende opdrachten uit om alle resources op te schonen:

# 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

Volgende stappen

Zie Access- en identiteitsopties voor AKS voor meer informatie over het beveiligen van Kubernetes-clusters.
Zie Best practices voor verificatie en autorisatie in AKS voor aanbevolen procedures voor identiteits- en resourcebeheer.

Delen via