Använda rollbaserad Kubernetes-åtkomstkontroll med Microsoft Entra-ID i Azure Kubernetes Service
Azure Kubernetes Service (AKS) kan konfigureras för att använda Microsoft Entra-ID för användarautentisering. I den här konfigurationen loggar du in på ett AKS-kluster med en Microsoft Entra-autentiseringstoken. När du har autentiserats kan du använda den inbyggda rollbaserade Åtkomstkontrollen för Kubernetes (Kubernetes RBAC) för att hantera åtkomst till namnområden och klusterresurser baserat på en användares identitets- eller gruppmedlemskap.
Den här artikeln visar hur du gör följande:
- Kontrollera åtkomsten med Kubernetes RBAC i ett AKS-kluster baserat på Microsoft Entra-gruppmedlemskap.
- Skapa exempelgrupper och användare i Microsoft Entra-ID.
- Skapa roller och rollbindningar i ett AKS-kluster för att ge lämpliga behörigheter för att skapa och visa resurser.
- Du har ett befintligt AKS-kluster med Microsoft Entra-integrering aktiverat. Om du behöver ett AKS-kluster med den här konfigurationen kan du läsa Integrera Microsoft Entra-ID med AKS.
- Kubernetes RBAC aktiveras som standard när AKS-klustret skapas. Om du vill uppgradera klustret med Microsoft Entra-integrering och Kubernetes RBAC aktiverar du Microsoft Entra-integrering i ditt befintliga AKS-kluster.
- Kontrollera att Azure CLI version 2.0.61 eller senare är installerad och konfigurerad. Kör
az --version
för att hitta versionen. Om du behöver installera eller uppgradera kan du läsa Installera Azure CLI. - Om du använder Terraform installerar du Terraform version 2.99.0 eller senare.
Använd Azure Portal eller Azure CLI för att verifiera att Microsoft Entra-integrering med Kubernetes RBAC är aktiverat.
Så här verifierar du med hjälp av Azure Portal:
- Logga in på Azure Portal och gå till aks-klusterresursen.
- I tjänstmenyn går du till Inställningar och väljer Klusterkonfiguration.
- Under avsnittet Autentisering och auktorisering kontrollerar du att alternativet Microsoft Entra-autentisering med Kubernetes RBAC är valt.
I den här artikeln skapar vi två användarroller för att visa hur Kubernetes RBAC och Microsoft Entra ID styr åtkomsten till klusterresurser. Följande två exempelroller används:
- Programutvecklare
- En användare med namnet aksdev som ingår i appdev-gruppen .
- Platstillförlitlighetstekniker
- En användare med namnet akssre som ingår i opssre-gruppen .
I produktionsmiljöer kan du använda befintliga användare och grupper i en Microsoft Entra-klientorganisation.
Hämta först resurs-ID:t för ditt AKS-kluster med hjälp av
az aks show
kommandot . Tilldela sedan resurs-ID:t till en variabel med namnet AKS_ID så att den kan refereras till i andra kommandon.AKS_ID=$(az aks show \ --resource-group myResourceGroup \ --name myAKSCluster \ --query id -o tsv)
Skapa den första exempelgruppen i Microsoft Entra-ID för programutvecklare med hjälp av
az ad group create
kommandot . I följande exempel skapas en grupp med namnet appdev:APPDEV_ID=$(az ad group create --display-name appdev --mail-nickname appdev --query id -o tsv)
Skapa en Azure-rolltilldelning för appdev-gruppen med kommandot
az role assignment create
. Med den här tilldelningen kan alla medlemmar i gruppen interagerakubectl
med ett AKS-kluster genom att ge dem användarrollen Azure Kubernetes Service Cluster .az role assignment create \ --assignee $APPDEV_ID \ --role "Azure Kubernetes Service Cluster User Role" \ --scope $AKS_ID
Tips
Om du får ett fel, till exempel Principal 35bfec9328bd4d8d9b54dea6dac57b82 doesn't exist in the directory a5443dcd-cd0e-494d-a387-3039b419f0d5.
, väntar du några sekunder på att microsoft Entra-gruppobjekt-ID:t ska spridas via katalogen och sedan försöka az role assignment create
med kommandot igen.
Skapa en andra exempelgrupp för SREs med namnet opssre.
OPSSRE_ID=$(az ad group create --display-name opssre --mail-nickname opssre --query id -o tsv)
Skapa en Azure-rolltilldelning för att bevilja medlemmar i gruppen användarrollen Azure Kubernetes Service-kluster .
az role assignment create \ --assignee $OPSSRE_ID \ --role "Azure Kubernetes Service Cluster User Role" \ --scope $AKS_ID
Nu när vi har två exempelgrupper som skapats i Microsoft Entra-ID för våra programutvecklare och SRE:er skapar vi två exempelanvändare. Om du vill testa Kubernetes RBAC-integreringen i slutet av artikeln loggar du in på AKS-klustret med dessa konton.
Ange användarens huvudnamn (UPN) och lösenordet för programutvecklare. UPN måste innehålla det verifierade domännamnet för din klientorganisation, till exempel aksdev@contoso.com
.
Följande kommando uppmanar dig att ange UPN och ställer in det på AAD_DEV_UPN så att det kan användas i ett senare kommando:
echo "Please enter the UPN for application developers: " && read AAD_DEV_UPN
Följande kommando uppmanar dig att ange lösenordet och ställer in det på AAD_DEV_PW för användning i ett senare kommando:
echo "Please enter the secure password for application developers: " && read AAD_DEV_PW
- Skapa det första användarkontot i Microsoft Entra-ID med kommandot
az ad user create
. I följande exempel skapas en användare med visningsnamnet AKS Dev och UPN och ett säkert lösenord med hjälp av värdena i AAD_DEV_UPN och 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)
- Lägg till användaren i appdev-gruppen som skapades i föregående avsnitt med kommandot
az ad group member add
.
az ad group member add --group appdev --member-id $AKSDEV_ID
- Konfigurera UPN och lösenordet för SRE. UPN måste innehålla det verifierade domännamnet för din klientorganisation, till exempel
akssre@contoso.com
. Följande kommando uppmanar dig att ange UPN och ställer in det på AAD_SRE_UPN för användning i ett senare kommando:
echo "Please enter the UPN for SREs: " && read AAD_SRE_UPN
- Följande kommando uppmanar dig att ange lösenordet och ställer in det på AAD_SRE_PW för användning i ett senare kommando:
echo "Please enter the secure password for SREs: " && read AAD_SRE_PW
- Skapa ett andra användarkonto. I följande exempel skapas en användare med visningsnamnet AKS SRE och UPN och ett säkert lösenord med hjälp av värdena i AAD_SRE_UPN och 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
Vi har skapat våra Microsoft Entra-grupper, användare och Azure-rolltilldelningar. Nu ska vi konfigurera AKS-klustret så att dessa olika grupper får åtkomst till specifika resurser.
- Hämta autentiseringsuppgifterna för klusteradministratören
az aks get-credentials
med kommandot . I något av följande avsnitt får du autentiseringsuppgifterna för det vanliga användarklustret för att se microsoft Entra-autentiseringsflödet i praktiken.
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --admin
- Skapa ett namnområde i AKS-klustret med kommandot
kubectl create namespace
. I följande exempel skapas ett namnområdesnamn dev:
kubectl create namespace dev
Anteckning
I Kubernetes definierar Roller de behörigheter som ska beviljas och Rollbindningar tillämpar dem på önskade användare eller grupper. Dessa tilldelningar kan tillämpas på ett givet namnområde eller i hela klustret. Mer information finns i Använda Kubernetes RBAC-auktorisering.
Om användaren som du beviljar Kubernetes RBAC-bindningen för finns i samma Microsoft Entra-klientorganisation tilldelar du behörigheter baserat på userPrincipalName (UPN). Om användaren finns i en annan Microsoft Entra-klientorganisation frågar du efter och använder egenskapen objectId i stället.
- Skapa en roll för dev-namnområdet , vilket ger fullständig behörighet till namnområdet. I produktionsmiljöer kan du ange mer detaljerade behörigheter för olika användare eller grupper. Skapa en fil med namnet
role-dev-namespace.yaml
och klistra in följande 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: ["*"]
- Skapa rollen med kommandot
kubectl apply
och ange filnamnet för YAML-manifestet.
kubectl apply -f role-dev-namespace.yaml
- Hämta resurs-ID:t för appdev-gruppen med kommandot
az ad group show
. Den här gruppen anges som ämne för ett RoleBinding i nästa steg.
az ad group show --group appdev --query id -o tsv
- Skapa en RoleBinding för appdev-gruppen för att använda den tidigare skapade rollen för namnområdesåtkomst. Skapa en fil med namnet
rolebinding-dev-namespace.yaml
och klistra in följande YAML-manifest. På den sista raden ersätter du groupObjectId med gruppobjektets ID-utdata från föregående kommando.
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
Tips
Om du vill skapa RoleBinding för en enskild användare anger du typ: Användare och ersätt groupObjectId med användarens huvudnamn (UPN) i exemplet ovan.
- Skapa RoleBinding med kommandot
kubectl apply
och ange filnamnet för DITT YAML-manifest:
kubectl apply -f rolebinding-dev-namespace.yaml
Nu ska vi upprepa föregående steg för att skapa ett namnområde, roll och rollbindning för SREs.
- Skapa ett namnområde för sre med kommandot
kubectl create namespace
.
kubectl create namespace sre
- Skapa en fil med namnet
role-sre-namespace.yaml
och klistra in följande 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: ["*"]
- Skapa rollen med kommandot
kubectl apply
och ange filnamnet för YAML-manifestet.
kubectl apply -f role-sre-namespace.yaml
- Hämta resurs-ID:t för opssre-gruppen med kommandot az ad group show .
az ad group show --group opssre --query id -o tsv
- Skapa en RoleBinding för opssre-gruppen för att använda den tidigare skapade rollen för namnområdesåtkomst. Skapa en fil med namnet
rolebinding-sre-namespace.yaml
och klistra in följande YAML-manifest. På den sista raden ersätter du groupObjectId med gruppobjektets ID-utdata från föregående kommando.
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
- Skapa RoleBinding med kommandot
kubectl apply
och ange filnamnet för DITT YAML-manifest.
kubectl apply -f rolebinding-sre-namespace.yaml
Nu ska vi testa att de förväntade behörigheterna fungerar när du skapar och hanterar resurser i ett AKS-kluster. I de här exemplen schemalägger och visar vi poddar i användarens tilldelade namnområde och försöker schemalägga och visa poddar utanför det tilldelade namnområdet.
- Återställ kubeconfig-kontexten
az aks get-credentials
med kommandot . I ett tidigare avsnitt anger du kontexten med autentiseringsuppgifterna för klusteradministratören. Administratörsanvändaren kringgår Microsoft Entra-inloggningsanvisningarna. Utan parametern tillämpas användarkontexten som kräver att alla begäranden autentiseras--admin
med hjälp av Microsoft Entra-ID.
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing
- Schemalägg en grundläggande NGINX-podd med kommandot
kubectl run
i dev-namnområdet .
kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
- Ange autentiseringsuppgifterna för ditt eget
appdev@contoso.com
konto som skapades i början av artikeln som inloggningsprompt. När du har loggat in cachelagras kontotoken för framtidakubectl
kommandon. NGINX har schemalagts, enligt följande exempelutdata:
$ 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
kubectl get pods
Använd kommandot för att visa poddar i dev-namnområdet.
kubectl get pods --namespace dev
- Kontrollera att statusen för NGINX-podden körs. Utdata ser ut ungefär som följande utdata:
$ kubectl get pods --namespace dev
NAME READY STATUS RESTARTS AGE
nginx-dev 1/1 Running 0 4m
Försök att visa poddar utanför dev-namnområdet . kubectl get pods
Använd kommandot igen, den här gången för att se --all-namespaces
.
kubectl get pods --all-namespaces
Användarens gruppmedlemskap har ingen Kubernetes-roll som tillåter den här åtgärden, vilket visas i följande exempelutdata:
Error from server (Forbidden): pods is forbidden: User "aksdev@contoso.com" cannot list resource "pods" in API group "" at the cluster scope
På samma sätt kan du försöka schemalägga en podd i ett annat namnområde, till exempel sre-namnområdet . Användarens gruppmedlemskap överensstämmer inte med en Kubernetes-roll och rollbindning för att bevilja dessa behörigheter, som du ser i följande exempelutdata:
$ 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"
Bekräfta att vårt Microsoft Entra-gruppmedlemskap och Kubernetes RBAC fungerar korrekt mellan olika användare och grupper genom att prova de tidigare kommandona när de loggas in som opssre-användare .
- Återställ kubeconfig-kontexten
az aks get-credentials
med kommandot som rensar den tidigare cachelagrade autentiseringstoken för aksdev-användaren.
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing
- Försök att schemalägga och visa poddar i det tilldelade sre-namnområdet . När du uppmanas till det loggar du in med dina egna
opssre@contoso.com
autentiseringsuppgifter som skapades i början av artikeln.
kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre
kubectl get pods --namespace sre
Som du ser i följande exempelutdata kan du skapa och visa poddarna:
$ 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
- Försök att visa eller schemalägga poddar utanför det tilldelade SRE-namnområdet.
kubectl get pods --all-namespaces
kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
Dessa kubectl
kommandon misslyckas, vilket visas i följande exempelutdata. Användarens gruppmedlemskap och Kubernetes-roll och rollbindningar beviljar inte behörighet att skapa eller hantera resurser i andra namnområden.
$ 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"
I den här artikeln har du skapat resurser i AKS-klustret och användare och grupper i Microsoft Entra-ID. Om du vill rensa alla resurser kör du följande kommandon:
# 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
Mer information om hur du skyddar Kubernetes-kluster finns i Åtkomst- och identitetsalternativ för AKS.
Metodtips för identitets- och resurskontroll finns i Metodtips för autentisering och auktorisering i AKS.
Feedback om Azure Kubernetes Service
Azure Kubernetes Service är ett öppen källkod projekt. Välj en länk för att ge feedback: