Best practices voor verificatie en autorisatie in Azure Kubernetes Service (AKS)

Artikel
02/16/2024

Wanneer u clusters implementeert en onderhoudt in Azure Kubernetes Service (AKS), implementeert u manieren om de toegang tot resources en services te beheren. Zonder deze besturingselementen:

Accounts kunnen toegang hebben tot onnodige resources en services.
Het kan lastig zijn om referenties bij te houden die worden gebruikt om wijzigingen aan te brengen.

In dit artikel bespreken we welke aanbevolen procedures een clusteroperator kan volgen om de toegang en identiteit voor AKS-clusters te beheren. U leert het volgende:

AKS-clustergebruikers verifiëren met Microsoft Entra-id.
Toegang tot resources beheren met op rollen gebaseerd toegangsbeheer van Kubernetes (Kubernetes RBAC).
Gebruik Azure RBAC om de toegang tot de AKS-resource, de Kubernetes-API op schaal en de kubeconfig.
Gebruik een workload-identiteit voor toegang tot Azure-resources vanuit uw pods.

Waarschuwing

De open source door Microsoft Entra beheerde identiteit (preview) in Azure Kubernetes Service is vanaf 10-24-2022 afgeschaft.

Als u een door Microsoft Entra-pod beheerde identiteit hebt ingeschakeld voor uw AKS-cluster of als u het wilt implementeren, raden we u aan het artikel over het overzicht van de workloadidentiteit te raadplegen om inzicht te krijgen in onze aanbevelingen en opties voor het instellen van uw cluster voor het gebruik van een Microsoft Entra Workload-ID (preview). Deze verificatiemethode vervangt door pod beheerde identiteit (preview), die kan worden geïntegreerd met de systeemeigen kubernetes-mogelijkheden om te federeren met externe id-providers.

Microsoft Entra-id gebruiken

Richtlijnen voor best practices

AKS-clusters implementeren met Microsoft Entra-integratie. Met Behulp van Microsoft Entra ID wordt de laag identiteitsbeheer gecentraliseerd. Elke wijziging in gebruikersaccount of groepsstatus wordt automatisch bijgewerkt in toegang tot het AKS-cluster. Bereik gebruikers of groepen tot de minimale machtigingshoeveelheid met behulp van Rollen, ClusterRoles of Bindingen.

Ontwikkelaars en toepassingseigenaren van uw Kubernetes-cluster hebben toegang nodig tot verschillende resources. Kubernetes beschikt niet over een oplossing voor identiteitsbeheer om de resources te beheren waarmee gebruikers kunnen communiceren. In plaats daarvan kunt u uw cluster integreren met een bestaande identiteitsoplossing, zoals Microsoft Entra ID, een oplossing voor identiteitsbeheer die gereed is voor ondernemingen.

Met geïntegreerde Microsoft Entra-clusters in AKS maakt u Rollen of ClusterRoles die toegangsmachtigingen voor resources definiëren. Vervolgens verbindt u de rollen aan gebruikers of groepen van Microsoft Entra ID. Meer informatie over deze Kubernetes RBAC vindt u in de volgende sectie. Microsoft Entra-integratie en hoe u de toegang tot resources kunt beheren, vindt u in het volgende diagram:

Cluster-level authentication for Microsoft Entra integration with AKS

Ontwikkelaars verifiëren met Microsoft Entra-id.
Het uitgifte-eindpunt van het Microsoft Entra-token geeft het toegangstoken uit.
De ontwikkelaar voert een actie uit met behulp van het Microsoft Entra-token, zoals kubectl create pod.
Kubernetes valideert het token met Microsoft Entra-id en haalt de groepslidmaatschappen van de ontwikkelaar op.
Kubernetes RBAC en clusterbeleid worden toegepast.
De aanvraag van de ontwikkelaar is geslaagd op basis van eerdere validatie van microsoft Entra-groepslidmaatschap en Kubernetes RBAC en beleid.

Zie Microsoft Entra-id integreren met AKS als u een AKS-cluster wilt maken dat gebruikmaakt van Microsoft Entra ID.

Op rollen gebaseerd toegangsbeheer van Kubernetes (Kubernetes RBAC) gebruiken

Richtlijnen voor best practices

Gebruikers- of groepsmachtigingen definiëren voor clusterbronnen met Kubernetes RBAC. Maak rollen en bindingen die de minimale hoeveelheid vereiste machtigingen toewijzen. Integreer met Microsoft Entra ID om elke wijziging van gebruikersstatus of groepslidmaatschap automatisch bij te werken en de toegang tot clusterbronnen actueel te houden.

In Kubernetes biedt u gedetailleerd toegangsbeheer voor clusterresources. U definieert machtigingen op clusterniveau of voor specifieke naamruimten. U bepaalt welke resources kunnen worden beheerd en met welke machtigingen. Vervolgens past u deze rollen toe op gebruikers of groepen met een binding. Zie Toegangs- en identiteitsopties voor Azure Kubernetes Service (AKS) voor meer informatie over rollen, clusterroles en bindingen.

U maakt bijvoorbeeld een rol met volledige toegang tot resources in de naamruimte finance-app, zoals wordt weergegeven in het volgende YAML-manifest:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role
  namespace: finance-app
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

Vervolgens maakt u een RoleBinding en verbindt u de Microsoft Entra-gebruiker developer1@contoso.com eraan, zoals wordt weergegeven in het volgende YAML-manifest:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role-binding
  namespace: finance-app
subjects:
- kind: User
  name: developer1@contoso.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: finance-app-full-access-role
  apiGroup: rbac.authorization.k8s.io

Wanneer developer1@contoso.com ze worden geverifieerd op basis van het AKS-cluster, hebben ze volledige machtigingen voor resources in de naamruimte finance-app . Op deze manier scheidt en bepaalt u de toegang tot resources logisch. Kubernetes RBAC gebruiken met Microsoft Entra ID-integratie.

Zie Toegang tot clusterbronnen beheren met behulp van op rollen gebaseerd toegangsbeheer en Microsoft Entra-identiteiten in AKS voor informatie over het gebruik van Microsoft Entra-groepen voor het beheren van toegang tot Kubernetes-resources met behulp van Kubernetes RBAC.

Azure RBAC gebruiken

Richtlijnen voor best practices

Gebruik Azure RBAC om de minimaal vereiste gebruikers- en groepsmachtigingen voor AKS-resources in een of meer abonnementen te definiëren.

Er zijn twee toegangsniveaus nodig om een AKS-cluster volledig te kunnen gebruiken:

Toegang tot de AKS-resource in uw Azure-abonnement.

Met dit toegangsniveau kunt u het volgende doen:
- Het schalen of upgraden van uw cluster beheren met behulp van de AKS-API's
- Trek je kubeconfig.
Zie Toegang tot clusterconfiguratiebestand beperken voor meer informatie over het beheren van de toegang tot de AKS-resource en de kubeconfigresource.
Toegang tot de Kubernetes-API.

Dit toegangsniveau wordt beheerd door:
- Kubernetes RBAC (traditioneel) of
- Door Azure RBAC te integreren met AKS voor kubernetes-autorisatie.
Zie Azure RBAC gebruiken voor Kubernetes-autorisatie voor meer informatie over het gedetailleerd verlenen van machtigingen aan de Kubernetes-API met behulp van Azure RBAC.

Door pod beheerde identiteiten gebruiken

Waarschuwing

De open source door Microsoft Entra beheerde identiteit (preview) in Azure Kubernetes Service is vanaf 10-24-2022 afgeschaft.

Gebruik geen vaste referenties binnen pods of containerinstallatiekopieën, omdat ze risico lopen op blootstelling of misbruik. Gebruik in plaats daarvan pod-identiteiten om automatisch toegang aan te vragen met behulp van Microsoft Entra-id.

Voor toegang tot andere Azure-resources, zoals Azure Cosmos DB, Key Vault of Blob Storage, heeft de pod verificatiereferenties nodig. U kunt verificatiereferenties definiëren met de containerinstallatiekopieën of deze injecteren als een Kubernetes-geheim. In beide gevallen moet u deze handmatig maken en toewijzen. Deze referenties worden meestal opnieuw gebruikt in pods en worden niet regelmatig geroteerd.

Met door pods beheerde identiteiten (preview) voor Azure-resources vraagt u automatisch toegang tot services aan via Microsoft Entra-id. Door pods beheerde identiteiten is momenteel in preview voor AKS. Raadpleeg de documentatie over het gebruik van door Microsoft Entra beheerde identiteiten in Azure Kubernetes Service (preview) om aan de slag te gaan.

Door Microsoft Entra beheerde identiteit (preview) ondersteunt twee bewerkingsmodi:

Standaardmodus : In deze modus worden de volgende twee onderdelen geïmplementeerd in het AKS-cluster:
- Managed Identity Controller (MIC): een Kubernetes-controller die controleert op wijzigingen in pods, AzureIdentity en AzureIdentityBinding via de Kubernetes API-server. Wanneer een relevante wijziging wordt gedetecteerd, voegt de MIC azureAssignedIdentity toe of verwijdert deze indien nodig. Wanneer een pod is gepland, wijst de MIC de beheerde identiteit in Azure toe aan de onderliggende virtuele-machineschaalset die tijdens de aanmaakfase wordt gebruikt door de knooppuntgroep. Wanneer alle pods die de identiteit gebruiken, worden verwijderd, wordt de identiteit verwijderd uit de virtuele-machineschaalset van de knooppuntgroep, tenzij dezelfde beheerde identiteit wordt gebruikt door andere pods. De MIC voert vergelijkbare acties uit wanneer AzureIdentity of AzureIdentityBinding wordt gemaakt of verwijderd.
- Managed Identity (NMI): is een pod die wordt uitgevoerd als een DaemonSet op elk knooppunt in het AKS-cluster. NMI onderschept beveiligingstokenaanvragen naar de Azure Instance Metadata Service op elk knooppunt. Hiermee worden aanvragen omgeleid naar zichzelf en wordt gevalideerd of de pod toegang heeft tot de identiteit waarvoor een token wordt aangevraagd en wordt het token opgehaald uit de Microsoft Entra-tenant namens de toepassing.
Beheerde modus: In deze modus is er alleen NMI. De identiteit moet handmatig worden toegewezen en beheerd door de gebruiker. Zie Pod Identity in Managed Mode voor meer informatie. Wanneer u in deze modus de opdracht az aks pod-identity add gebruikt om een pod-identiteit toe te voegen aan een AKS-cluster (Azure Kubernetes Service), worden de AzureIdentity en AzureIdentityBinding gemaakt in de naamruimte die is opgegeven door de --namespace parameter, terwijl de AKS-resourceprovider de beheerde identiteit toewijst die is opgegeven door de --identity-resource-id parameter aan de virtuele-machineschaalset van elke knooppuntgroep in het AKS-cluster.

Notitie

Als u in plaats daarvan besluit om de door Microsoft Entra-pod beheerde identiteit te installeren met behulp van de AKS-clusterinvoegtoepassing, wordt de managed modus gebruikt.

De managed modus biedt de volgende voordelen ten opzichte van:standard

Identiteitstoewijzing in de virtuele-machineschaalset van een knooppuntgroep kan 40-60s duren. Met cronjobs of toepassingen waarvoor toegang tot de identiteit is vereist en de toewijzingsvertraging niet kan worden getolereerd, kunt u de modus het beste gebruiken managed omdat de identiteit vooraf is toegewezen aan de virtuele-machineschaalset van de knooppuntgroep. Handmatig of met de opdracht az aks pod-identity add .
In standard de modus vereist MIC schrijfmachtigingen voor de virtuele-machineschaalset die wordt gebruikt door het AKS-cluster en Managed Identity Operator machtigingen voor de door de gebruiker toegewezen beheerde identiteiten. Wanneer u werkt managed mode, omdat er geen MIC is, zijn de roltoewijzingen niet vereist.

In plaats van referenties voor pods handmatig te definiëren, vragen door pods beheerde identiteiten in realtime een toegangstoken aan, waarbij deze alleen toegang heeft tot hun toegewezen resources. In AKS zijn er twee onderdelen die de bewerkingen verwerken om pods toe te staan beheerde identiteiten te gebruiken:

De NMI-server (Node Management Identity) is een pod die wordt uitgevoerd als een DaemonSet op elk knooppunt in het AKS-cluster. De NMI-server luistert naar podaanvragen naar Azure-services.
De Azure-resourceprovider voert een query uit op de Kubernetes-API-server en controleert op een Azure-identiteitstoewijzing die overeenkomt met een pod.

Wanneer pods een beveiligingstoken aanvragen van Microsoft Entra ID voor toegang tot een Azure-resource, leiden netwerkregels het verkeer om naar de NMI-server.

De NMI-server:
- Identificeert pods die toegang tot Azure-resources aanvragen op basis van hun externe adres.
- Query's uitvoeren op de Azure-resourceprovider.
De Azure-resourceprovider controleert op Azure-identiteitstoewijzingen in het AKS-cluster.
De NMI-server vraagt een toegangstoken van Microsoft Entra-id aan op basis van de identiteitstoewijzing van de pod.
Microsoft Entra-id biedt toegang tot de NMI-server, die wordt geretourneerd naar de pod.
- Dit toegangstoken kan door de pod worden gebruikt om vervolgens toegang tot resources in Azure aan te vragen.

In het volgende voorbeeld maakt een ontwikkelaar een pod die gebruikmaakt van een beheerde identiteit om toegang tot Azure SQL Database aan te vragen:

Pod identities allow a pod to automatically request access to other resources.

Clusteroperator maakt een serviceaccount om identiteiten toe te wijzen wanneer pods toegang tot resources aanvragen.
De NMI-server wordt geïmplementeerd om podaanvragen, samen met de Azure-resourceprovider, door te sturen voor toegangstokens naar Microsoft Entra-id.
Een ontwikkelaar implementeert een pod met een beheerde identiteit die een toegangstoken aanvraagt via de NMI-server.
Het token wordt geretourneerd naar de pod en wordt gebruikt voor toegang tot Azure SQL Database

Zie Microsoft Entra pod-beheerde identiteiten gebruiken in Azure Kubernetes Service (preview) voor informatie over het gebruik van door pods beheerde identiteiten.

Volgende stappen

Dit artikel met aanbevolen procedures is gericht op verificatie en autorisatie voor uw cluster en resources. Raadpleeg de volgende artikelen om enkele van deze aanbevolen procedures te implementeren:

Zie de volgende aanbevolen procedures voor meer informatie over clusterbewerkingen in AKS: