Concepten voor clusterverificatie in Azure Kubernetes Service (AKS)

In dit artikel wordt beschreven hoe Azure Kubernetes Service (AKS) aanroepers verifieert bij de Kubernetes-API, dat wil gezegd, wie verbinding kan maken met het besturingsvlak. Het behandelt het aanbevolen verificatiepad op basis van Microsoft Entra ID en het vergrendelen van break-glass-toegang.

Zie concepten voor clusterautorisatie voor meer informatie over hoe AKS evalueert wat een geverifieerde beller mag doen.

Zie voor de andere identiteitsscenario's in AKS:

Zie Opties voor toegang en identiteit voor AKS voor een overzicht van alle vier AKS-identiteitsscenario's.

Authentiseren bij de Kubernetes API server (control plane)

Kubernetes zelf biedt geen identiteitsmap. Zonder een externe identiteitsprovider moet u lokale referenties per cluster beheren, wat niet schaalbaar is en het creëert audit-lacunes.

U wordt aangeraden AKS-clusters te implementeren met Microsoft Entra ID-verificatie voor het besturingsvlak. Met deze integratie valideert het cluster binnenkomende Kubernetes API-aanvragen voor Microsoft Entra ID en gebruikt de Entra-identiteit van de aanroeper voor autorisatiebeslissingen. Microsoft Entra ID centraliseert de identiteitslaag( elke wijziging in de gebruikers- of groepsstatus wordt automatisch doorgevoerd in clustertoegang) en maakt voorwaardelijke toegang, meervoudige verificatie en Privileged Identity Management mogelijk.

Diagram met Microsoft Entra-integratie met AKS-clusters voor verificatie.

Zie voor de installatie Microsoft Entra ID-verificatie inschakelen voor het AKS-besturingsvlak. Let op het volgende:

  • De Microsoft Entra-tenant die is geconfigureerd voor clusterverificatie, moet hetzelfde zijn als de tenant van het abonnement dat het AKS-cluster bevat.
  • Gebruik de kubectl invoegtoepassing voor niet-interactieve aanmeldingen of oudere kubelogin versies.

Externe identiteitsproviders (voorvertoning)

Sommige organisaties moeten clustergebruikers verifiëren met een andere id-provider die compatibel is met OIDC dan Microsoft Entra-id, bijvoorbeeld GitHub, Google Workspace, Okta of een zelf-hostende IdP. AKS ondersteunt dit via gestructureerde verificatie, waarmee de JWT-verificators van de Kubernetes-API-server worden geconfigureerd om tokens te valideren die zijn uitgegeven door uw externe provider.

Gebruik deze optie alleen als u een harde vereiste hebt om de clusteridentiteit buiten Microsoft Entra-id te houden. Anders geeft u de voorkeur aan het Microsoft Entra ID-pad voor uitgebreidere integratie met voorwaardelijke toegang, meervoudige verificatie en Privileged Identity Management.

Zie Verificatie van externe id-providers voor AKS-clusters voor een overzicht. Zie Externe id-providers configureren met gestructureerde AKS-verificatie voor de installatie.

Uitschakelen van lokale accounts

Lokale accounts maken gebruik van een ingebouwd clusterbeheerderscertificaat dat Microsoft Entra-id omzeilt. Elke beller die deze referentie kan vermelden, krijgt volledige toegang tot de clusterbeheerder zonder de Entra-id te doorlopen, waardoor gecentraliseerde controle, voorwaardelijke toegang en Privileged Identity Management wordt onderbreekt. Schakel in productie lokale accounts uit zodat alle toegang via Microsoft Entra-id stroomt.

Om dit op grote schaal af te dwingen in veel clusters, wijs de ingebouwde Azure Policy Azure Kubernetes Service-clusters moeten lokale verificatiemethoden uitschakelen toe op het niveau van een abonnement of beheergroep. Het beleid controleert en kan clusters weigeren die zijn gemaakt of bijgewerkt waarbij lokale accounts zijn ingeschakeld. Zie ingebouwde Azure Policy-definities voor AKS voor een volledige lijst met ingebouwde AKS-beleidsregels.

Zie Lokale accounts beheren in AKS voor meer informatie.

Verifiëren bij clusterknooppunten

SSH-toegangsmodi

Naast verificatie bij de Kubernetes-API moet u mogelijk ook rechtstreeks verifiëren bij een knooppunt via SSH voor probleemoplossing. AKS ondersteunt drie SSH-toegangsmodi die u per cluster of knooppuntgroep instelt:

  • Uitgeschakelde SSH (preview): SSH-toegang tot knooppunten volledig blokkeren. Aanbevolen voor productie waarbij toegang op knooppuntniveau alleen wordt beheerd via kubectl debug of andere Kubernetes-systeemeigen paden.
  • Op Microsoft Entra ID gebaseerde SSH (preview): meld u aan bij knooppunten met behulp van Microsoft Entra-identiteiten, zonder dat er SSH-sleutels hoeven te worden beheerd. Deze modus is consistent met de rest van de clusterverificatie: deze neemt voorwaardelijke toegang en meervoudige verificatie over van Entra ID, ondersteunt Just-In-Time-uitbreiding via Azure RBAC en Privileged Identity Management en centraliseert controle via entra-id-aanmeldingslogboeken.
  • SSH van lokale gebruiker: traditionele toegang op basis van SSH-sleutels. Gebruik dit alleen wanneer SSH op basis van Entra-id geen optie is en sleutels regelmatig roteert.

Zie SSH-toegang beheren op AKS-clusterknooppunten voor installatie- en configuratiestappen per modus.

Volgende stappen 

  • Last updated on