Kubelogin gebruiken om gebruikers te verifiëren in Azure Kubernetes Service (AKS)

De kubelogin-invoegtoepassing in Azure is een invoegtoepassing voor client-go-referenties waarmee Microsoft Entra-verificatie wordt geïmplementeerd. De kubelogin-invoegtoepassing biedt functies die niet beschikbaar zijn in het opdrachtregelprogramma kubectl. Zie de kubelogin-inleiding en de kubectl-inleiding voor meer informatie.

Dit artikel bevat een overzicht en voorbeelden van het gebruik van kubelogin voor ondersteunde Microsoft Entra verificatiemethoden die worden aanbevolen voor AKS.

Beperkingen van Kubelogin-verificatie in AKS

  • Groepen die zijn gemaakt in Microsoft Entra, worden alleen opgenomen door hun ObjectID-waarde en niet door hun weergavenaam. De sAMAccountName opdracht is alleen beschikbaar voor groepen die worden gesynchroniseerd vanuit on-premises Windows Server Active Directory.
  • De verificatiemethode van de service-principal werkt alleen met beheerde Microsoft Entra ID-integratie, niet met verouderde Microsoft Entra ID-integratie.
  • De service-principal kan lid zijn van maximaal 200 Microsoft Entra-groepen. Als u meer dan 200 groepen hebt, kunt u overwegen om toepassingsrollen te gebruiken.
  • De verificatiemethode voor apparaatcode werkt niet wanneer een Beleid voor voorwaardelijke toegang van Microsoft Entra is ingesteld op een Microsoft Entra-tenant. In dat scenario gebruikt u in plaats daarvan interactieve verificatie van webbrowsers.
  • De verificatiemethode van Azure CLI werkt alleen met Microsoft Entra.

Hoe kubelogin-verificatie werkt in AKS

AKS-clusters waarop Kubernetes versie 1.24 of hoger wordt uitgevoerd, gebruiken automatisch de indeling van de kubelogin-exec-invoegtoepassing. Voor clusters met Kubernetes-versies ouder dan 1.24 is handmatige conversie naar deze indeling vereist.

Gebruik voor de meeste interacties met kubelogin de subopdracht convert-kubeconfig. De subopdracht maakt gebruik van het kubeconfig-bestand dat u opgeeft in --kubeconfig of in de KUBECONFIG omgevingsvariabele om het uiteindelijke kubeconfig-bestand te converteren naar exec-indeling op basis van de opgegeven verificatiemethode.

De verificatiemethoden die kubelogin implementeert, zijn Microsoft Entra OAuth 2.0 token-vergunningsstromen. Cachegedrag is afhankelijk van de verificatiemethode. Apparaatcode-, interactieve webbrowser- en resource owner password credential (ROPC)-verificatie slaan authenticatierecords op in de kubelogin-cachemap. Methoden zoals Azure CLI en Azure Developer CLI gebruiken de cache die wordt beheerd door hun respectieve opdrachtregelprogramma in plaats van de kubelogin-cache.

Verificatie van apparaatcode

Apparaatcode is de standaardverificatiemethode voor de convert-kubeconfig subopdracht. Met deze verificatiemethode wordt de apparaatcode opgevraagd zodat de gebruiker zich kan aanmelden vanuit een browsersessie.

Notitie

Voordat de kubelogin- en exec-invoegtoepassingen werden geïntroduceerd, ondersteunde de Azure-verificatiemethode in kubectl alleen de apparaatcodestroom. Er is een eerdere versie van een bibliotheek gebruikt die een token produceert dat de audience claim met een spn: voorvoegsel heeft. Het is niet compatibel met Microsoft Entra, dat gebruikmaakt van een on-behalf-of (OBO)-flow. Wanneer u de convert-kubeconfig subopdracht uitvoert, verwijdert kubelogin het spn: voorvoegsel uit de doelgroepclaim.

Parameters voor verificatie van apparaatcode

De volgende tabel bevat een overzicht van parameters die u kunt gebruiken met verificatie van apparaatcode:

Kenmerk Description
-l devicecode (optioneel) Hiermee geeft u de kubelogin-verificatiemethode op. Deze parameter is optioneel omdat apparaatcode de standaardmethode is.
--legacy Gebruikt verouderd gedrag voor clusters die zijn geconfigureerd met verouderde Microsoft Entra ID-integratie. Als het kubeconfig-bestand voor een dergelijk cluster is, voegt kubelogin automatisch de --legacy vlag toe.
--cache-dir Overschrijft het standaardpad van de tokencachemap. Dit is ${HOME}/.kube/cache/kubelogin.

Azure CLI-verificatie

De verificatiemethode van Azure CLI (opdracht: -l azurecli) maakt gebruik van de aangemelde context die de Azure CLI tot stand brengt om het toegangstoken op te halen. Het token wordt uitgegeven in dezelfde Microsoft Entra-tenant als az login. kubelogin schrijft geen tokens naar het tokencachebestand omdat deze al worden beheerd door de Azure CLI.

Parameters voor Azure CLI-verificatie

De volgende tabel bevat een overzicht van parameters die u kunt gebruiken met Azure CLI-verificatie:

Kenmerk Description
-l azurecli Hiermee geeft u de kubelogin-verificatiemethode op.
--azure-config-dir Hiermee geeft u de Azure CLI-configuratiemap op. De standaardmap is ${HOME}/.azure.

Aanmelden bij Azure

Meld u aan bij Azure met behulp van de az login opdracht.

az login

Interactieve verificatie van webbrowser

Met de interactieve methode van de webbrowser (opdracht: -l interactive) voor verificatie wordt automatisch een webbrowser geopend om de gebruiker aan te melden. Nadat de gebruiker is geverifieerd, wordt de browser omgeleid naar de lokale webserver met behulp van de geverifieerde referenties. Deze verificatiemethode voldoet aan het beleid voor voorwaardelijke toegang.

U kunt een Bearer-token of een PoP-token (Proof-of-Possession) gebruiken met deze verificatiemethode.

Parameters voor bearer-tokenverificatie

De volgende tabel bevat parameters die u kunt gebruiken met bearer-tokenverificatie:

Kenmerk Description
-l interactive Hiermee geeft u de kubelogin-verificatiemethode op.
--cache-dir Overschrijft het standaardpad van de tokencachemap. Dit is ${HOME}/.kube/cache/kubelogin.

Parameters voor PoP-tokenverificatie

De volgende tabel bevat een overzicht van parameters die u kunt gebruiken met PoP-tokenverificatie:

Kenmerk Description
-l interactive Hiermee geeft u de kubelogin-verificatiemethode op.
--pop-enabled Hiermee schakelt u PoP-tokenverificatie in.
--pop-claims Hiermee geeft u de PoP-tokenclaims in een sleutel-waardepaarindeling op. Bijvoorbeeld: u=/ARM/ID/OF/CLUSTER.

Authenticatie van service-principal

De verificatiemethode voor de service-principal (opdracht: -l spn) maakt gebruik van een service-principal om de gebruiker aan te melden. U kunt de referentie opgeven door een omgevingsvariabele in te stellen of door de referentie in een opdrachtregelargument te gebruiken. De ondersteunde referenties die u kunt gebruiken, zijn een wachtwoord of een PFX-clientcertificaat (Personal Information Exchange).

Parameters voor authenticatie van de service-principal

De volgende tabel geeft een overzicht van parameters die u kunt gebruiken met service-principalverificatie:

Kenmerk Description
-l spn Hiermee geeft u de kubelogin-verificatiemethode op.
--client-id De applicatie-ID (client-id) van de service-principal.
--client-secret Het clientgeheim van de service-principal.

Verificatie van beheerde identiteit

Gebruik de beheerde identiteit (opdracht: -l msi) verificatiemethode voor toepassingen die verbinding maken met resources die ondersteuning bieden voor Microsoft Entra-verificatie. Voorbeelden hiervan zijn toegang tot Azure resources, zoals een Azure virtuele machine (VM), Virtual Machine Scale Sets of Azure Cloud Shell.

U kunt de standaard beheerde identiteit gebruiken die is toegewezen aan de resource of een specifieke door de gebruiker toegewezen beheerde identiteit.

Parameters voor verificatie van beheerde identiteit

De volgende tabel bevat een overzicht van parameters die u kunt gebruiken met verificatie van beheerde identiteiten:

Kenmerk Description
-l msi Hiermee geeft u de kubelogin-verificatiemethode op.
--client-id De toepassings-id (client-id) van de door de gebruiker toegewezen beheerde identiteit. Als u deze parameter niet opgeeft, wordt de standaard beheerde identiteit gebruikt.

Verificatie van workload identiteit

De verificatiemethode voor workloadidentiteit (opdracht: -l workloadidentity) maakt gebruik van identiteitsreferenties die zijn gefedereerd met Microsoft Entra om toegang tot AKS-clusters te verifiëren. De methode maakt gebruik van geïntegreerde Microsoft Entra-verificatie. Het werkt door de volgende omgevingsvariabelen in te stellen:

Variable Description
AZURE_CLIENT_ID De Microsoft Entra-toepassings-id die is gefedereerd met de workloadidentiteit.
AZURE_TENANT_ID De Tenant-id van Microsoft Entra.
AZURE_FEDERATED_TOKEN_FILE Het bestand dat een ondertekende assertie van de workloadidentiteit bevat, zoals een Kubernetes-token voor een geprojecteerde service account (JWT).
AZURE_AUTHORITY_HOST De basis-URL van een Microsoft Entra-instantie. Bijvoorbeeld: https://login.microsoftonline.com/.

U kunt een workloadidentiteit gebruiken om toegang te krijgen tot Kubernetes-clusters vanuit CI/CD-systemen, zoals GitHub of Argo CD, zonder de referenties van de service-principal op te slaan in de externe systemen. Om OIDC (OpenID Connect) federatie vanuit GitHub te configureren, zie het OIDC-federatievoorbeeld.

Parameters voor workload-identiteitsverificatie

De volgende tabel geeft een overzicht van parameterinstellingen die u kunt gebruiken met workload-identiteit verificatie.

Kenmerk Description
-l workloadidentity Hiermee geeft u de kubelogin-verificatiemethode op.

CLI-verificatie voor ontwikkelaars Azure

De verificatiemethode Azure Developer CLI (opdracht: -l azd) maakt gebruik van de aangemelde context die de Azure Developer CLI tot stand brengt om het toegangstoken op te halen. Het token wordt uitgegeven in dezelfde Microsoft Entra-tenant als azd auth login. kubelogin schrijft geen tokens naar de tokencache omdat de Azure Developer CLI deze beheert.

Deze verificatiemethode werkt alleen met beheerde Microsoft Entra in AKS. Zie het overzicht van Azure Developer CLI voor meer informatie.

Verificatie van Azure-pipelines

De verificatiemethode Azure-pipelines (opdracht: -l azurepipelines) maakt gebruik van een Azure Resource Manager serviceverbinding en het systeemtoegangstoken van de pijplijn om te verifiëren. Deze methode werkt alleen in Azure-pipelines. De pijplijn moet een Azure Resource Manager-serviceverbinding hebben en scripts toegang geven tot het OAuth-token.

Wanneer u een AzureCLI@2 taak gebruikt met een Azure Resource Manager-serviceverbinding, kan kubelogin de tenant-id, client-id en serviceverbindings-id gebruiken die Azure-pipelines als omgevingsvariabelen biedt. Zie Azure-pipelines serviceverbindingen voor meer informatie.

Warning

kubelogin ondersteunt ook de authenticatiemethode met wachtwoordaanmeldingsgegevens van de eigenaar van de resource (ROPC). Microsoft raadt u aan ROPC niet te gebruiken omdat deze niet compatibel is met meervoudige verificatie en een aantal hybride identiteitsscenario's. Zie de Microsoft identity platform ROPC-richtlijnen voor meer informatie.

Het kubeconfig-bestandspad exporteren

Voordat u de convert-kubeconfig subopdracht uitvoert, exporteert u het kubeconfig-bestandspad naar de KUBECONFIG omgevingsvariabele. Voorbeeld:

export KUBECONFIG=/path/to/kubeconfig

Het kubeconfig-bestand converteren

Voer de convert-kubeconfig subopdracht uit om het kubeconfig-bestand te converteren om de exec-invoegtoepassing te gebruiken voor de gekozen verificatiemethode.

kubelogin convert-kubeconfig
kubelogin convert-kubeconfig -l azurecli
# Bearer token authentication
kubelogin convert-kubeconfig -l interactive

# Proof-of-Possession (PoP) token authentication
kubelogin convert-kubeconfig -l interactive --pop-enabled --pop-claims "u=/ARM/ID/OF/CLUSTER"
  1. Voer de convert-kubeconfig subopdracht uit om het kubeconfig-bestand te converteren om de exec-invoegtoepassing te gebruiken.

    kubelogin convert-kubeconfig -l spn
    
  2. Stel de omgevingsvariabelen in voor de client-id en het clientgeheim of het clientcertificaat. Voorbeeld:

    export AZURE_CLIENT_ID=<service-principal-client-id>
    export AZURE_CLIENT_SECRET=<service-principal-client-secret>
    
# Default managed identity authentication
kubelogin convert-kubeconfig -l msi

# Specific managed identity authentication
kubelogin convert-kubeconfig -l msi --client-id <managed-identity-client-id>
kubelogin convert-kubeconfig -l workloadidentity

Het kubeconfig-bestand converteren met behulp van de Azure Developer CLI

  1. Meld u aan met behulp van de Azure Developer CLI.

    azd auth login
    
  2. Converteer het kubeconfig-bestand om de verificatiemethode Azure Developer CLI te gebruiken.

    kubelogin convert-kubeconfig -l azd
    

Het kubeconfig-bestand converteren in Azure-pipelines

Converteer in een AzureCLI@2 taak die gebruikmaakt van een Azure Resource Manager-serviceverbinding het kubeconfig-bestand om Azure-pipelines verificatie te gebruiken.

kubelogin convert-kubeconfig -l azurepipelines

Tokens in cache verwijderen

Verwijder tokens in de cache met behulp van de kubelogin remove-cache-dir opdracht.

kubelogin remove-cache-dir

Knooppuntgegevens ophalen

Haal knooppuntgegevens op met behulp van de kubectl get opdracht.

kubectl get nodes

Kubelogin-toepassings-id’s gebruiken met AKS

AKS maakt gebruik van een paar eigen Microsoft Entra-toepassingen. Deze toepassings-id's zijn in alle omgevingen hetzelfde.

Application Toepassings-id (GUID) Gebruikt in
AKS-server-applicatie (--server-id) 6dae42f8-4368-4678-94ff-3960e28e3630 De token-doelgroep voor alle ondersteunde kubelogin-authenticatiemethoden bij toegang tot AKS.
Openbare clienttoepassing voor AKS (--client-id) 80faf920-1908-4b52-b5ef-a8e7bedfc67a Apparaatcode, interactieve webbrowser en ROPC-authenticatie.

Wanneer u rechtstreeks voor AKS aanroept kubelogin get-token , geeft u de AKS-servertoepassings-id op met --server-id. Zie de kubelogin-verwijzing get-tokenvoor modusspecifieke parameters.

Notitie

De id van de openbare clienttoepassing van AKS in deze sectie is de waarde --client-id voor apparaatcodeverificatie, interactieve verificatie via webbrowser en ROPC-authenticatie. Voor service-principal- en verificatie met beheerde identiteit identificeert --client-id in plaats daarvan de service-principal of de door de gebruiker toegewezen beheerde identiteit.

Haal bijvoorbeeld een token op met behulp van apparaatcodeverificatie en de AKS-toepassings-id's:

kubelogin get-token \
    --login devicecode \
    --server-id 6dae42f8-4368-4678-94ff-3960e28e3630 \
    --client-id 80faf920-1908-4b52-b5ef-a8e7bedfc67a \
    --tenant-id <microsoft-entra-tenant-id>