Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Den här artikeln beskriver hur Azure Kubernetes Service (AKS) bestämmer vad en autentiserad anropare får göra mot Kubernetes-API:et. Den omfattar de två auktoriseringsmodeller som AKS stöder och detaljerad anpassad resurskontroll med Azure ABAC-villkor.
Information om hur AKS autentiserar anropare finns i Begrepp för klusterautentisering.
En orientering över alla fyra AKS-identitetsscenarier finns i Åtkomst- och identitetsalternativ för AKS.
Auktorisera Kubernetes API
När en anropare har autentiserats utvärderar AKS om anroparen har behörighet att utföra den begärda åtgärden. AKS stöder två auktoriseringsmodeller för Kubernetes API:
- Rollbaserad åtkomstkontroll för Kubernetes (RBAC). Den inbyggda Kubernetes-auktoriseringsmodellen. Behörigheter definieras som
RoleochClusterRoleobjekt och beviljas till ämnen viaRoleBindingochClusterRoleBindingobjekt som lagras i varje kluster. - Microsoft Entra-ID-auktorisering. En AKS-auktoriseringswebbhook som delegerar auktoriseringsbeslut till Microsoft Entra-ID. Behörigheter beviljas som Azure-rolltilldelningar till Entra-ID-identiteter och kan eventuellt förfinas med Azure ABAC-villkor.
Du kan använda båda modellerna i samma kluster. Vi rekommenderar Microsoft Entra ID-auktorisering som standard och reserverar Kubernetes RBAC för detaljerade behörigheter inom klustret. Resten av det här avsnittet förklarar varför och när du ska använda var och en.
Kubernetes RBAC
Kubernetes RBAC är den överordnade Kubernetes-auktoriseringsmodellen. Du skapar Role eller ClusterRole objekt som beviljar verb (till exempel get, list, create) för resurser (till exempel pods, deployments) och binder dem till ämnen (användare, grupper eller tjänstkonton) med hjälp av RoleBinding eller ClusterRoleBinding objekt. Kubernetes API-serverns inbyggda RBAC-auktoriserare utvärderar dessa bindningar för varje begäran.
Använd Kubernetes RBAC när du vill:
- Detaljerad intraklusteråtkomstkontroll per namnområde som skapats som Kubernetes-manifest tillsammans med de arbetslaster som de skyddar.
- GitOps-hanterad auktorisering som finns i samma sanningskälla som programkonfigurationen.
- Behörigheter för tjänstkonton i kluster som arbetsbelastningar använder för att anropa Kubernetes-API:et.
Kubernetes RBAC-behörigheter är begränsade till ett enda kluster. Om du vill tillämpa samma princip på många kluster måste du tillämpa manifesten på varje kluster (vanligtvis via GitOps). Använd Microsoft Entra-användare och -grupper som ämnen i Kubernetes RoleBinding och ClusterRoleBinding objekt så att mänskliga identiteter fortfarande kommer från din centrala katalog.
Bakgrund om Kubernetes RBAC-modellen finns i den överordnade Kubernetes RBAC-dokumentationen. Konfiguration i AKS finns i Använda Kubernetes RBAC med Microsoft Entra-integrering.
Microsoft Entra-ID-auktorisering för Kubernetes API
Med Entra ID-auktorisering distribuerar AKS en auktoriseringswebbhook som delegerar Kubernetes API-auktoriseringsbeslut till Microsoft Entra-ID. När en begäran når API-servern anropar webhooken Api:et Entra ID checkaccess för att utvärdera anroparens Azure-rolltilldelningar (och eventuella anslutna ABAC-villkor) och returnerar ett beslut om att tillåta eller neka.
Entra ID-auktorisering ger dig följande fördelar jämfört med att hantera Kubernetes RBAC-manifest i varje kluster:
- Ett enda identitetsplan. Samma Microsoft Entra-användare, grupper och tjänstens huvudnamn som styr åtkomsten till dina Azure-resurser styr även åtkomsten till ditt Kubernetes-API. Det finns ingen separat användarkatalog att etablera eller rotera.
- Tilldela en gång, hantera många kluster. Azure-rolltilldelningar kan göras i prenumeration, hanteringsgrupp eller resursgruppsomfång. En enskild rolltilldelning i ett resursgruppsomfång ger åtkomst till varje aktuellt och framtida AKS-kluster i den resursgruppen. Med Kubernetes RBAC måste du tillämpa manifest på varje kluster individuellt.
- Villkorlig åtkomst och privilegierad identitetshantering (PIM). Klusteråtkomst ärver automatiskt organisationens befintliga principer för villkorlig åtkomst för Entra-ID (till exempel multifaktorautentisering eller platsbaserade begränsningar) och kan utökas just-in-time via PIM.
- Centraliserad granskning. Varje ändring av rolltilldelning registreras i Azure-aktivitetsloggen tillsammans med andra Azure-resursändringar, så du har en spårningslogg för styrning av klusteråtkomst.
- Detaljerade anpassade resursbegränsningar. Med ABAC-villkor kan du begränsa åtkomsten till specifika anpassade resursgrupper (CRD) och typer utan att skriva Kubernetes RBAC-manifest per kluster.
AKS tillhandahåller följande inbyggda roller för Entra ID-auktorisering:
| Befattning | Description |
|---|---|
| RBAC-läsare för Azure Kubernetes Service | Skrivskyddad åtkomst till de flesta objekt i ett namnområde. Tillåter inte visning av roller, rollbindningar eller Secrets. |
| Azure Kubernetes Service RBAC Writer | Läs-/skrivåtkomst till de flesta objekt i ett namnområde. Tillåter inte visning eller ändring av roller eller rollbindningar. |
| Azure Kubernetes Service RBAC-administratör | Läs-/skrivåtkomst till de flesta resurser i ett namnområde, plus möjligheten att skapa roller och rollbindningar i namnområdet. |
| RBAC-klusteradministratör för Azure Kubernetes Service | Fullständig kontroll över varje resurs i klustret, över alla namnområden. |
För anpassade behörighetsmönster kan du skapa anpassade rolldefinitioner som riktar sig mot specifika Kubernetes API-grupper med hjälp av Microsoft.ContainerService resursproviderns dataåtgärder. Stegvisa konfigurations- och anpassade rollexempel finns i Använda Microsoft Entra ID-auktorisering för Kubernetes API.
Comparison
| Förmåga | Kubernetes RBAC | Auktorisering för Entra-ID |
|---|---|---|
| Identitetskälla | Kubernetes-användare, grupper, tjänstkonton | Microsoft Entra-ID-identiteter |
| Omfång för ett enskilt bidrag | Ett kluster | Resurs, resursgrupp, prenumeration eller hanteringsgrupp |
| Styrning av flera kluster | Tillämpa manifest på varje kluster (vanligtvis GitOps) | En rolltilldelning med ett högre omfång styr många kluster |
| Villkorlig åtkomst/PIM | Stöds ej | Ärvt från Entra-ID |
| Redovisningsspårning | Klustergranskningslogg | Azure-aktivitetslogg |
| Filtrera åtkomst efter CRD-grupp eller typ | Skapa per CRD-objekt Role |
Använda ABAC-villkorsattribut för rolltilldelningen |
Begränsa anpassad resursåtkomst med ABAC-villkor
När du beviljar bred läsåtkomst via Microsoft Entra ID-auktorisering men vill begränsa vilka anpassade resurser (CRD) som tilldelad kan läsa, bifogar du ett Azure ABAC-villkor till rolltilldelningen.
Utan ABAC-villkor kräver beviljandet av läsbehörighet för anpassade resurser ett jokertecken som Microsoft.ContainerService/managedClusters/*/read, som omfattar varje CRD på varje kluster i omfånget. Med ABAC kan du koppla ett villkor som begränsar åtkomsten till specifika CRD-grupper och typer – till exempel tillåt templates.gatekeeper.sh vid blockering kyverno.io – utan att skriva Kubernetes RBAC-manifest per kluster.
För Kubernetes API-auktorisering kan du filtrera åtkomsten till anpassade resurser efter deras API-grupp och typ med hjälp av följande attribut:
Microsoft.ContainerService/managedClusters/customResources:groupMicrosoft.ContainerService/managedClusters/customResources:kind
Bakgrund om Azure ABAC finns i Vad är villkor för Rolltilldelning i Azure?. Stegvis konfiguration finns i Begränsa åtkomst till anpassade resurser med abac-villkor.