Dela via


Åtkomst och identitetsalternativ för Azure Kubernetes Service (AKS)

Du kan autentisera, auktorisera, skydda och kontrollera åtkomsten till Kubernetes-kluster på flera olika sätt:

  • Med kubernetes rollbaserad åtkomstkontroll (Kubernetes RBAC) kan du endast ge användare, grupper och tjänstkonton åtkomst till de resurser de behöver.
  • Med Azure Kubernetes Service (AKS) kan du ytterligare förbättra säkerhets- och behörighetsstrukturen med hjälp av Microsoft Entra ID och Azure RBAC.

Kubernetes RBAC och AKS hjälper dig att skydda klusteråtkomsten och endast ge de minsta behörigheter som krävs för utvecklare och operatörer.

Den här artikeln beskriver de grundläggande begreppen som hjälper dig att autentisera och tilldela behörigheter i AKS.

Kubernetes RBAC

Kubernetes RBAC tillhandahåller detaljerad filtrering av användaråtgärder. Med den här kontrollmekanismen:

  • Du tilldelar användare eller användargrupper behörighet att skapa och ändra resurser eller visa loggar från programarbetsbelastningar som körs.
  • Du kan begränsa behörigheter till ett enda namnområde eller i hela AKS-klustret.
  • Du skapar roller för att definiera behörigheter och tilldelar sedan dessa roller till användare med rollbindningar.

Mer information finns i Använda Kubernetes RBAC-auktorisering.

Roller och ClusterRoles

Roller

Innan du tilldelar behörigheter till användare med Kubernetes RBAC definierar du användarbehörigheter som en roll. Bevilja behörigheter inom ett namnområde med hjälp av roller.

Kommentar

Kubernetes-roller beviljar behörigheter. De nekar inte behörigheter.

Om du vill bevilja behörigheter över hela klustret eller till klusterresurser utanför ett angivet namnområde kan du i stället använda ClusterRoles.

ClusterRoles

En ClusterRole beviljar och tillämpar behörigheter för resurser i hela klustret, inte ett specifikt namnområde.

RoleBindings och ClusterRoleBindings

När du har definierat roller för att bevilja behörigheter till resurser tilldelar du dessa Kubernetes RBAC-behörigheter med ett Rollbinding. Om AKS-klustret integreras med Microsoft Entra-ID beviljar RoleBindings behörigheter till Microsoft Entra-användare för att utföra åtgärder i klustret. Se hur du kontrollerar åtkomsten till klusterresurser med hjälp av rollbaserad åtkomstkontroll i Kubernetes och Microsoft Entra-identiteter.

Rollbindningar

Tilldela roller till användare för ett angivet namnområde med hjälp av RoleBindings. Med RoleBindings kan du logiskt separera ett enda AKS-kluster, vilket bara gör det möjligt för användare att komma åt programresurserna i sitt tilldelade namnområde.

Om du vill binda roller över hela klustret eller till klusterresurser utanför ett angivet namnområde använder du i stället ClusterRoleBindings.

ClusterRoleBinding

Med en ClusterRoleBinding binder du roller till användare och tillämpar på resurser i hela klustret, inte ett specifikt namnområde. Med den här metoden kan du ge administratörer eller supporttekniker åtkomst till alla resurser i AKS-klustret.

Kommentar

Microsoft/AKS utför alla klusteråtgärder med användarmedgivande under en inbyggd Kubernetes-roll aks-service och inbyggd rollbindning aks-service-rolebinding.

Den här rollen gör det möjligt för AKS att felsöka och diagnostisera klusterproblem, men kan inte ändra behörigheter eller skapa roller eller rollbindningar eller andra åtgärder med hög behörighet. Rollåtkomst aktiveras endast under aktiva supportärenden med just-in-time-åtkomst (JIT). Läs mer om AKS-supportprinciper.

Kubernetes-tjänstkonton

Tjänstkonton är en av de primära användartyperna i Kubernetes. Kubernetes API innehåller och hanterar tjänstkonton. Autentiseringsuppgifter för tjänstkonto lagras som Kubernetes-hemligheter, vilket gör att de kan användas av auktoriserade poddar för att kommunicera med API-servern. De flesta API-begäranden tillhandahåller en autentiseringstoken för ett tjänstkonto eller ett normalt användarkonto.

Vanliga användarkonton ger mer traditionell åtkomst för mänskliga administratörer eller utvecklare, inte bara tjänster och processer. Kubernetes tillhandahåller ingen identitetshanteringslösning för att lagra vanliga användarkonton och lösenord, men du kan integrera externa identitetslösningar i Kubernetes. För AKS-kluster är den här integrerade identitetslösningen Microsoft Entra-ID.

Mer information om identitetsalternativen i Kubernetes finns i Kubernetes-autentisering.

Azure rollbaserad åtkomstkontroll

Rollbaserad åtkomstkontroll i Azure (RBAC) är ett auktoriseringssystem som bygger på Azure Resource Manager och som ger detaljerad åtkomsthantering av Azure-resurser.

RBAC-system beskrivning
Kubernetes RBAC Utformad för att fungera med Kubernetes-resurser i ditt AKS-kluster.
Azure RBAC Utformad för att fungera med resurser i din Azure-prenumeration.

Med Azure RBAC skapar du en rolldefinition som beskriver de behörigheter som ska tillämpas. Sedan tilldelar du en användare eller grupp den här rolldefinitionen via en rolltilldelning för ett visst omfång. Omfånget kan vara en enskild resurs, en resursgrupp eller i hela prenumerationen.

Mer information finns i Vad är rollbaserad åtkomstkontroll i Azure (Azure RBAC)?

Det finns två åtkomstnivåer som krävs för att köra ett AKS-kluster fullt ut:

Azure RBAC för att auktorisera åtkomst till AKS-resursen

Med Azure RBAC kan du ge dina användare (eller identiteter) detaljerad åtkomst till AKS-resurser i en eller flera prenumerationer. Du kan till exempel använda rollen Azure Kubernetes Service-deltagare för att skala och uppgradera klustret. Under tiden har en annan användare med azure Kubernetes-tjänstklusteradministratörsrollen endast behörighet att hämta administratören kubeconfig.

Använd Azure RBAC för att definiera åtkomst till Kubernetes-konfigurationsfilen i AKS.

Azure RBAC för Kubernetes-auktorisering

Med Azure RBAC-integreringen använder AKS en Kubernetes Authorization webhook-server så att du kan hantera Microsoft Entra-integrerade Kubernetes-klusterresursbehörigheter och tilldelningar med hjälp av Azure-rolldefinitioner och rolltilldelningar.

Azure RBAC för Kubernetes-auktoriseringsflöde

Som du ser i diagrammet ovan följer alla begäranden till Kubernetes-API:et samma autentiseringsflöde som beskrivs i avsnittet Microsoft Entra-integrering när du använder Azure RBAC-integreringen.

Om den identitet som gör begäran finns i Microsoft Entra-ID samarbetar Azure med Kubernetes RBAC för att auktorisera begäran. Om identiteten finns utanför Microsoft Entra-ID (dvs. ett Kubernetes-tjänstkonto) kommer auktoriseringen att skjutas upp till den normala Kubernetes RBAC.

I det här scenariot använder du Azure RBAC-mekanismer och API:er för att tilldela användare inbyggda roller eller skapa anpassade roller, precis som med Kubernetes-roller.

Med den här funktionen ger du inte bara användarna behörighet till AKS-resursen mellan prenumerationer, utan du konfigurerar även rollen och behörigheterna för i vart och ett av dessa kluster som styr Kubernetes API-åtkomst. Du kan till exempel bevilja rollen i Azure Kubernetes Service RBAC Reader prenumerationsomfånget. Rollmottagaren kan lista och hämta alla Kubernetes-objekt från alla kluster utan att ändra dem.

Viktigt!

Du måste aktivera Azure RBAC för Kubernetes-auktorisering innan du använder den här funktionen. Mer information och steg för steg-vägledning finns i instruktionsguiden Använd Azure RBAC för Kubernetes-auktorisering .

Inbyggda roller

AKS innehåller följande fyra inbyggda roller. De liknar de inbyggda Kubernetes-rollerna med några skillnader, till exempel stöd för CRD:er. Se den fullständiga listan över åtgärder som tillåts av varje inbyggd Azure-roll.

Roll beskrivning
RBAC-läsare för Azure Kubernetes Service Tillåter skrivskyddad åtkomst för att se de flesta objekt i ett namnområde.
Tillåter inte visning av roller eller rollbindningar.
Tillåter inte visning Secrets. Secrets Genom att läsa innehållet får du åtkomst till ServiceAccount autentiseringsuppgifter i namnområdet, vilket skulle ge API-åtkomst som alla ServiceAccount i namnområdet (en form av eskalering av privilegier).
Azure Kubernetes Service RBAC Writer Tillåter läs-/skrivåtkomst till de flesta objekt i ett namnområde.
Tillåter inte visning eller ändring av roller eller rollbindningar.
Tillåter åtkomst till Secrets och körning av poddar som alla ServiceAccount i namnområdet, så det kan användas för att få API-åtkomstnivåerna för alla ServiceAccount i namnområdet.
RBAC-administratör för Azure Kubernetes Service Tillåter administratörsåtkomst, avsedd att beviljas inom ett namnområde.
Tillåter läs-/skrivåtkomst till de flesta resurser i ett namnområde (eller klusteromfång), inklusive möjligheten att skapa roller och rollbindningar i namnområdet.
Tillåter inte skrivåtkomst till resurskvoten eller till själva namnområdet.
RBAC-klusteradministratör för Azure Kubernetes Service Tillåter superanvändaråtkomst för att utföra alla åtgärder på alla resurser.
Ger fullständig kontroll över varje resurs i klustret och i alla namnområden.

Microsoft Entra-integrering

Förbättra säkerheten för AKS-kluster med Microsoft Entra-integrering. Microsoft Entra ID bygger på årtionden av företagsidentitetshantering och är en molnbaserad katalog- och identitetshanteringstjänst för flera klientorganisationer som kombinerar kärnkatalogtjänster, hantering av programåtkomst och identitetsskydd. Med Microsoft Entra-ID kan du integrera lokala identiteter i AKS-kluster för att tillhandahålla en enda källa för kontohantering och säkerhet.

Microsoft Entra-integrering med AKS-kluster

Med Microsoft Entra-integrerade AKS-kluster kan du ge användare eller grupper åtkomst till Kubernetes-resurser inom ett namnområde eller i hela klustret.

  1. För att få en kubectl konfigurationskontext kör en användare kommandot az aks get-credentials .
  2. När en användare interagerar med AKS-klustret med kubectluppmanas de att logga in med sina Microsoft Entra-autentiseringsuppgifter.

Den här metoden ger en enda källa för hantering av användarkonton och autentiseringsuppgifter för lösenord. Användaren kan bara komma åt resurserna enligt klusteradministratörens definition.

Microsoft Entra-autentisering tillhandahålls till AKS-kluster med OpenID Connect. OpenID Connect är ett identitetslager som bygger på OAuth 2.0-protokollet. Mer information om OpenID Connect finns i OpenID Connect-dokumentationen. Inifrån Kubernetes-klustret används Webhook Token Authentication för att verifiera autentiseringstoken. Webhook-tokenautentisering konfigureras och hanteras som en del av AKS-klustret.

Webhook- och API-server

Webhook- och API-serverautentiseringsflöde

Som du ser i bilden ovan anropar API-servern AKS webhook-servern och utför följande steg:

  1. kubectl använder Microsoft Entra-klientprogrammet för att logga in användare med OAuth 2.0-enhetsauktoriseringsflödet.
  2. Microsoft Entra ID tillhandahåller en access_token, id_token och en refresh_token.
  3. Användaren skickar en begäran till kubectl med en access_token från kubeconfig.
  4. kubectl skickar access_token till API Server.
  5. API-servern har konfigurerats med Auth WebHook-servern för att utföra validering.
  6. Webhook-autentiseringsservern bekräftar att signaturen för JSON-webbtoken är giltig genom att kontrollera den offentliga signeringsnyckeln för Microsoft Entra.
  7. Serverprogrammet använder användarangivna autentiseringsuppgifter för att fråga efter gruppmedlemskap för den inloggade användaren från MS Graph-API:et.
  8. Ett svar skickas till API-servern med användarinformation, till exempel UPN-anspråket (user principal name) för åtkomsttoken och gruppmedlemskapet för användaren baserat på objekt-ID:t.
  9. API:et utför ett auktoriseringsbeslut baserat på Kubernetes-rollen/rollbindningen.
  10. När api-servern har godkänts returnerar den ett svar på kubectl.
  11. kubectl ger feedback till användaren.

Lär dig hur du integrerar AKS med Microsoft Entra ID med vår AKS-hanterade Microsoft Entra-integreringsguide.

AKS-tjänstbehörigheter

När du skapar ett kluster genererar eller ändrar AKS resurser som behövs (till exempel virtuella datorer och nätverkskort) för att skapa och köra klustret åt användaren. Den här identiteten skiljer sig från klustrets identitetsbehörighet, som skapas när klustret skapas.

Identitet som skapar och kör klusterbehörigheterna

Följande behörigheter krävs av identiteten som skapar och använder klustret.

Behörighet Anledning
Microsoft.Compute/diskEncryptionSets/read Krävs för att läsa diskkrypteringsuppsättnings-ID.
Microsoft.Compute/proximityPlacementGroups/write Krävs för uppdatering av närhetsplaceringsgrupper.
Microsoft.Network/applicationGateways/read
Microsoft.Network/applicationGateways/write
Microsoft.Network/virtualNetworks/subnets/join/action
Krävs för att konfigurera programgatewayer och ansluta till undernätet.
Microsoft.Network/virtualNetworks/subnets/join/action Krävs för att konfigurera nätverkssäkerhetsgruppen för undernätet när du använder ett anpassat VNET.
Microsoft.Network/publicIPAddresses/join/action
Microsoft.Network/publicIPPrefixes/join/action
Krävs för att konfigurera utgående offentliga IP-adresser på Standard Load Balancer.
Microsoft.OperationalInsights/workspaces/sharedkeys/read
Microsoft.OperationalInsights/workspaces/read
Microsoft.OperationsManagement/solutions/write
Microsoft.OperationsManagement/solutions/read
Microsoft.ManagedIdentity/userAssignedIdentities/assign/action
Krävs för att skapa och uppdatera Log Analytics-arbetsytor och Azure-övervakning för containrar.
Microsoft.Network/virtualNetworks/joinLoadBalancer/action Krävs för att konfigurera IP-baserade lastbalanserarens serverdelspooler.

Behörigheter för AKS-klusteridentitet

Följande behörigheter används av AKS-klusteridentiteten, som skapas och associeras med AKS-klustret. Varje behörighet används av följande orsaker:

Behörighet Anledning
Microsoft.ContainerService/managedClusters/*
Krävs för att skapa användare och använda klustret
Microsoft.Network/loadBalancers/delete
Microsoft.Network/loadBalancers/read
Microsoft.Network/loadBalancers/write
Krävs för att konfigurera lastbalanseraren för en LoadBalancer-tjänst.
Microsoft.Network/publicIPAddresses/delete
Microsoft.Network/publicIPAddresses/read
Microsoft.Network/publicIPAddresses/write
Krävs för att hitta och konfigurera offentliga IP-adresser för en LoadBalancer-tjänst.
Microsoft.Network/publicIPAddresses/join/action Krävs för att konfigurera offentliga IP-adresser för en LoadBalancer-tjänst.
Microsoft.Network/networkSecurityGroups/read
Microsoft.Network/networkSecurityGroups/write
Krävs för att skapa eller ta bort säkerhetsregler för en LoadBalancer-tjänst.
Microsoft.Compute/disks/delete
Microsoft.Compute/disks/read
Microsoft.Compute/disks/write
Microsoft.Compute/locations/DiskOperations/read
Krävs för att konfigurera AzureDisks.
Microsoft.Storage/storageAccounts/delete
Microsoft.Storage/storageAccounts/listKeys/action
Microsoft.Storage/storageAccounts/read
Microsoft.Storage/storageAccounts/write
Microsoft.Storage/operations/read
Krävs för att konfigurera lagringskonton för AzureFile eller AzureDisk.
Microsoft.Network/routeTables/read
Microsoft.Network/routeTables/routes/delete
Microsoft.Network/routeTables/routes/read
Microsoft.Network/routeTables/routes/write
Microsoft.Network/routeTables/write
Krävs för att konfigurera routningstabeller och vägar för noder.
Microsoft.Compute/virtualMachines/read Krävs för att hitta information för virtuella datorer i en VMAS, till exempel zoner, feldomän, storlek och datadiskar.
Microsoft.Compute/virtualMachines/write Krävs för att ansluta AzureDisks till en virtuell dator i en VMAS.
Microsoft.Compute/virtualMachineScaleSets/read
Microsoft.Compute/virtualMachineScaleSets/virtualMachines/read
Microsoft.Compute/virtualMachineScaleSets/virtualmachines/instanceView/read
Krävs för att hitta information för virtuella datorer i en VM-skalningsuppsättning, till exempel zoner, feldomän, storlek och datadiskar.
Microsoft.Network/networkInterfaces/write Krävs för att lägga till en virtuell dator i en VMAS i en lastbalanserares serverdelsadresspool.
Microsoft.Compute/virtualMachineScaleSets/write Krävs för att lägga till en VM-skalningsuppsättning till en lastbalanserares serverdelsadresspooler och skala ut noder i en VM-skalningsuppsättning.
Microsoft.Compute/virtualMachineScaleSets/delete Krävs för att ta bort en VM-skalningsuppsättning till en lastbalanserares serverdelsadresspooler och skala ned noder i en VM-skalningsuppsättning.
Microsoft.Compute/virtualMachineScaleSets/virtualmachines/write Krävs för att ansluta AzureDisks och lägga till en virtuell dator från en VM-skalningsuppsättning till lastbalanseraren.
Microsoft.Network/networkInterfaces/read Krävs för att söka efter virtuella datorer i en VMAS för interna IP-adresser och lastbalanserares serverdelsadresspooler.
Microsoft.Compute/virtualMachineScaleSets/virtualMachines/networkInterfaces/read Krävs för att söka efter interna IP-adresser och lastbalanserarens serverdelsadresspooler efter en virtuell dator i en VM-skalningsuppsättning.
Microsoft.Compute/virtualMachineScaleSets/virtualMachines/networkInterfaces/ipconfigurations/publicipaddresses/read Krävs för att hitta offentliga IP-adresser för en virtuell dator i en VM-skalningsuppsättning.
Microsoft.Network/virtualNetworks/read
Microsoft.Network/virtualNetworks/subnets/read
Krävs för att kontrollera om det finns ett undernät för den interna lastbalanseraren i en annan resursgrupp.
Microsoft.Compute/snapshots/delete
Microsoft.Compute/snapshots/read
Microsoft.Compute/snapshots/write
Krävs för att konfigurera ögonblicksbilder för AzureDisk.
Microsoft.Compute/locations/vmSizes/read
Microsoft.Compute/locations/operations/read
Krävs för att hitta storlekar på virtuella datorer för att hitta Volymgränser för AzureDisk.

Ytterligare behörigheter för klusteridentitet

När du skapar ett kluster med specifika attribut behöver du följande ytterligare behörigheter för klusteridentiteten. Eftersom dessa behörigheter inte tilldelas automatiskt måste du lägga till dem i klusteridentiteten när den har skapats.

Behörighet Anledning
Microsoft.Network/networkSecurityGroups/write
Microsoft.Network/networkSecurityGroups/read
Krävs om du använder en nätverkssäkerhetsgrupp i en annan resursgrupp. Krävs för att konfigurera säkerhetsregler för en LoadBalancer-tjänst.
Microsoft.Network/virtualNetworks/subnets/read
Microsoft.Network/virtualNetworks/subnets/join/action
Krävs om du använder ett undernät i en annan resursgrupp, till exempel ett anpassat virtuellt nätverk.
Microsoft.Network/routeTables/routes/read
Microsoft.Network/routeTables/routes/write
Krävs om du använder ett undernät som är associerat med en routningstabell i en annan resursgrupp, till exempel ett anpassat VNET med en anpassad routningstabell. Krävs för att kontrollera om det redan finns ett undernät för undernätet i den andra resursgruppen.
Microsoft.Network/virtualNetworks/subnets/read Krävs om du använder en intern lastbalanserare i en annan resursgrupp. Krävs för att kontrollera om det redan finns ett undernät för den interna lastbalanseraren i resursgruppen.
Microsoft.Network/privatednszones/* Krävs om du använder en privat DNS-zon i en annan resursgrupp, till exempel en anpassad privateDNSZone.

ÅTKOMST TILL AKS-nod

Som standard krävs inte nodåtkomst för AKS. Följande åtkomst krävs för noden om en specifik komponent används.

Access Anledning
kubelet Krävs för att bevilja MSI-åtkomst till ACR.
http app routing Krävs för skrivbehörighet till "slumpmässigt namn".aksapp.io.
container insights Krävs för att bevilja behörighet till Log Analytics-arbetsytan.

Sammanfattning

Visa tabellen för en snabb sammanfattning av hur användare kan autentisera till Kubernetes när Microsoft Entra-integrering är aktiverat. I samtliga fall är användarens sekvens med kommandon:

  1. Kör az login för att autentisera till Azure.

  2. Kör az aks get-credentials för att ladda ned autentiseringsuppgifter för klustret till .kube/config.

  3. Kör kubectl kommandon.

    • Det första kommandot kan utlösa webbläsarbaserad autentisering för att autentisera till klustret enligt beskrivningen i följande tabell.

I Azure Portal hittar du:

  • Rolltilldelningen (Azure RBAC-rolltilldelning) som avses i den andra kolumnen visas på fliken Åtkomstkontroll.
  • Gruppen Klusteradministratör Microsoft Entra visas på fliken Konfiguration .
    • Hittades också med parameternamnet --aad-admin-group-object-ids i Azure CLI.
beskrivning Rollbidrag krävs Klusteradministratör Microsoft Entra-grupper Användningsområde för
Äldre administratörsinloggning med klientcertifikat Administratörsroll för Azure Kubernetes-tjänstkluster. Den här rollen kan användas med --admin flaggan, som hämtar ett äldre (icke-Microsoft Entra) klusteradministratörscertifikat till användarens .kube/config.az aks get-credentials Det här är det enda syftet med "Administratörsroll för Azure Kubernetes Service-kluster". saknas Om du är permanent blockerad genom att inte ha åtkomst till en giltig Microsoft Entra-grupp med åtkomst till klustret.
Microsoft Entra-ID med manuella (kluster)Rollbindningar Användarroll för Azure Kubernetes Service-kluster. Rollen "Användare" kan az aks get-credentials användas utan --admin flaggan. (Det här är det enda syftet med "Användarroll för Azure Kubernetes Service-kluster".) Resultatet i ett Microsoft Entra-ID-aktiverat kluster är nedladdningen av en tom post till .kube/config, som utlöser webbläsarbaserad autentisering när den först används av kubectl. Användaren finns inte i någon av dessa grupper. Eftersom användaren inte finns i några klusteradministratörsgrupper styrs deras rättigheter helt av rollbindningar eller ClusterRoleBindings som har konfigurerats av klusteradministratörer. Rollbindningarna (Kluster) nominerar Microsoft Entra-användare eller Microsoft Entra-grupper som deras subjects. Om inga sådana bindningar har konfigurerats kan användaren inte ta bort några kubectl kommandon. Om du vill ha detaljerad åtkomstkontroll och inte använder Azure RBAC för Kubernetes-auktorisering. Observera att användaren som konfigurerar bindningarna måste logga in med någon av de andra metoderna som anges i den här tabellen.
Microsoft Entra-ID efter medlem i administratörsgruppen Samma som ovan Användaren är medlem i en av grupperna som anges här. AKS genererar automatiskt en ClusterRoleBinding som binder alla listade grupper till cluster-admin Kubernetes-rollen. Så att användare i dessa grupper kan köra alla kubectl kommandon som cluster-admin. Om du enkelt vill ge användarna fullständiga administratörsrättigheter och inte använder Azure RBAC för Kubernetes-auktorisering.
Microsoft Entra-ID med Azure RBAC för Kubernetes-auktorisering Två roller:
Först Azure Kubernetes Service Cluster User Role (som ovan).
För det andra en av "Azure Kubernetes Service RBAC..." eller ditt eget anpassade alternativ.
Fältet administratörsroller på fliken Konfiguration är irrelevant när Azure RBAC för Kubernetes-auktorisering är aktiverat. Du använder Azure RBAC för Kubernetes-auktorisering. Den här metoden ger dig detaljerad kontroll, utan att behöva konfigurera RoleBindings eller ClusterRoleBindings.

Nästa steg

Mer information om grundläggande Kubernetes- och AKS-begrepp finns i följande artiklar: