Share via

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

  • Artikel

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.

Azure Kubernetes Service-clusters (AKS) die zijn geïntegreerd met Microsoft Entra ID en kubernetes versie 1.24 of hoger gebruiken automatisch de kubelogin-indeling.

Dit artikel bevat een overzicht en voorbeelden van het gebruik van kubelogin voor alle ondersteunde Microsoft Entra-verificatiemethoden in AKS.

Beperkingen

  • U kunt maximaal 200 groepen opnemen in een Microsoft Entra JSON-webtokenclaim (JWT). Als u meer dan 200 groepen hebt, kunt u overwegen om toepassingsrollen te gebruiken.
  • Groepen die zijn gemaakt in Microsoft Entra-id, 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.
  • In AKS werkt de verificatiemethode voor de service-principal alleen met beheerde Microsoft Entra-id en niet met de eerdere versie van Azure Active Directory.
  • 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 interactieve webbrowserverificatie.

Hoe verificatie werkt

Voor de meeste interacties met kubelogin gebruikt u de convert-kubeconfig subopdracht. De subopdracht maakt gebruik van het kubeconfig-bestand dat is opgegeven 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-tokentoekentoekenstromen. De volgende parametervlagmen zijn gebruikelijk voor gebruik in kubelogin-subopdrachten. Over het algemeen zijn deze vlaggen klaar om te gebruiken wanneer u het kubeconfig-bestand van AKS krijgt.

  • --tenant-id: de Tenant-id van Microsoft Entra.
  • --client-id: de toepassings-id van de openbare clienttoepassing. Deze client-app wordt alleen gebruikt in de aanmeldingsmethoden voor apparaatcode, webbrowser interactief en OAuth 2.0 Resource Owner Password Credentials (ROPC) (werkstroomidentiteit).
  • --server-id: De toepassings-id van de web-app of resourceserver. Het token wordt uitgegeven aan deze resource.

Notitie

In elke verificatiemethode wordt het token niet in de cache opgeslagen in het bestandssysteem.

Verificatiemethoden

In de volgende secties worden ondersteunde verificatiemethoden beschreven en hoe u deze kunt gebruiken:

  • Apparaatcode
  • Azure-CLI
  • Webbrowser interactief
  • Service-principal
  • Beheerde identiteit
  • Workload-identiteit

Apparaatcode

Apparaatcode is de standaardverificatiemethode voor de convert-kubeconfig subopdracht. De -l devicecode parameter is optioneel. Met deze verificatiemethode wordt de apparaatcode gevraagd voor de gebruiker om zich aan te melden vanuit een browsersessie.

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 door AKS beheerde Microsoft Entra ID, die gebruikmaakt van een on-behalf-of -stroom (OBO). Wanneer u de convert-kubeconfig subopdracht uitvoert, verwijdert kubelogin het spn: voorvoegsel uit de doelgroepclaim.

Als uw vereisten functionaliteit uit eerdere versies bevatten, voegt u het --legacy argument toe. Als u het kubeconfig-bestand in een Azure Active Directory-cluster van een eerdere versie gebruikt, voegt kubelogin automatisch de --legacy vlag toe.

In deze aanmeldingsmethode worden het toegangstoken en het vernieuwingstoken in de cache opgeslagen in de map ${HOME}/.kube/cache/kubelogin . Als u dit pad wilt overschrijven, neemt u de --token-cache-dir parameter op.

Als uw geïntegreerde AKS Microsoft Entra-cluster Kubernetes 1.24 of eerder gebruikt, moet u de kubeconfig-bestandsindeling handmatig converteren door de volgende opdrachten uit te voeren:

export KUBECONFIG=/path/to/kubeconfig
kubelogin convert-kubeconfig

Voer deze kubectl-opdracht uit om knooppuntgegevens op te halen:

kubectl get nodes

Voer de volgende opdracht uit om tokens in de cache op te schonen:

kubelogin remove-tokens

Notitie

De aanmeldingsmethode voor apparaatcode werkt niet wanneer een beleid voor voorwaardelijke toegang is geconfigureerd op een Microsoft Entra-tenant. In dit scenario gebruikt u de interactieve methode van de webbrowser.

Azure-CLI

De Verificatiemethode van Azure CLI 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.

Notitie

Deze verificatiemethode werkt alleen met de door AKS beheerde Microsoft Entra-id.

In het volgende voorbeeld ziet u hoe u de Azure CLI-methode gebruikt om te verifiëren:

az login

export KUBECONFIG=/path/to/kubeconfig

kubelogin convert-kubeconfig -l azurecli

Voer deze kubectl-opdracht uit om knooppuntgegevens op te halen:

kubectl get nodes

Als de Azure CLI-configuratiemap zich buiten de map ${HOME} bevindt, gebruikt u de --azure-config-dir parameter met de convert-kubeconfig subopdracht. Met de opdracht wordt het kubeconfig-bestand gegenereerd met de omgevingsvariabele die is geconfigureerd. U kunt dezelfde configuratie krijgen door de AZURE_CONFIG_DIR omgevingsvariabele in te stellen op deze map wanneer u een kubectl-opdracht uitvoert.

Webbrowser interactief

Met de interactieve verificatiemethode van de webbrowser 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.

Wanneer u verifieert met deze methode, wordt het toegangstoken in de cache opgeslagen in de map ${HOME}/.kube/cache/kubelogin . U kunt dit pad overschrijven met behulp van de --token-cache-dir parameter.

Bearer-token

In het volgende voorbeeld ziet u hoe u een Bearer-token gebruikt met de interactieve webbrowserstroom:

export KUBECONFIG=/path/to/kubeconfig

kubelogin convert-kubeconfig -l interactive

Voer deze kubectl-opdracht uit om knooppuntgegevens op te halen:

kubectl get nodes

Proof-of-Possession-token

In het volgende voorbeeld ziet u hoe u een PoP-token (Proof-of-Possession) gebruikt met de interactieve stroom van de webbrowser:

export KUBECONFIG=/path/to/kubeconfig

kubelogin convert-kubeconfig -l interactive --pop-enabled --pop-claims "u=/ARM/ID/OF/CLUSTER"

Voer deze kubectl-opdracht uit om knooppuntgegevens op te halen:

kubectl get nodes

Service-principal

Deze verificatiemethode 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).

Voordat u deze methode gebruikt, moet u rekening houden met de volgende beperkingen:

  • Deze methode werkt alleen met beheerde Microsoft Entra-id.
  • De service-principal kan lid zijn van maximaal 200 Microsoft Entra-groepen.

Omgevingsvariabelen

In het volgende voorbeeld ziet u hoe u een clientgeheim instelt met behulp van omgevingsvariabelen:

export KUBECONFIG=/path/to/kubeconfig

kubelogin convert-kubeconfig -l spn

export AAD_SERVICE_PRINCIPAL_CLIENT_ID=<Service Principal Name (SPN) client ID>
export AAD_SERVICE_PRINCIPAL_CLIENT_SECRET=<SPN secret>

Voer deze kubectl-opdracht uit om knooppuntgegevens op te halen:

kubectl get nodes

Voer vervolgens deze opdracht uit:

export KUBECONFIG=/path/to/kubeconfig

kubelogin convert-kubeconfig -l spn

export AZURE_CLIENT_ID=<SPN client ID>
export AZURE_CLIENT_SECRET=<SPN secret>

Voer deze kubectl-opdracht uit om knooppuntgegevens op te halen:

kubectl get nodes

Opdrachtregelargument

In het volgende voorbeeld ziet u hoe u een clientgeheim instelt in een opdrachtregelargument:

export KUBECONFIG=/path/to/kubeconfig

kubelogin convert-kubeconfig -l spn --client-id <SPN client ID> --client-secret <SPN client secret>

Voer deze kubectl-opdracht uit om knooppuntgegevens op te halen:

kubectl get nodes

Waarschuwing

Met de opdrachtregelargumentmethode wordt het geheim opgeslagen in het kubeconfig-bestand.

Clientcertificaat

In het volgende voorbeeld ziet u hoe u een clientgeheim instelt met behulp van een clientcertificaat:

export KUBECONFIG=/path/to/kubeconfig

kubelogin convert-kubeconfig -l spn

export AAD_SERVICE_PRINCIPAL_CLIENT_ID=<SPN client ID>
export AAD_SERVICE_PRINCIPAL_CLIENT_CERTIFICATE=/path/to/cert.pfx
export AAD_SERVICE_PRINCIPAL_CLIENT_CERTIFICATE_PASSWORD=<PFX password>

Voer deze kubectl-opdracht uit om knooppuntgegevens op te halen:

kubectl get nodes

Voer vervolgens deze opdracht uit:

export KUBECONFIG=/path/to/kubeconfig

kubelogin convert-kubeconfig -l spn

export AZURE_CLIENT_ID=<SPN client ID>
export AZURE_CLIENT_CERTIFICATE_PATH=/path/to/cert.pfx
export AZURE_CLIENT_CERTIFICATE_PASSWORD=<PFX password>

Voer deze kubectl-opdracht uit om knooppuntgegevens op te halen:

kubectl get nodes

PoP-token en omgevingsvariabelen

In het volgende voorbeeld ziet u hoe u een PoP-token instelt dat gebruikmaakt van een clientgeheim dat wordt opgehaald uit omgevingsvariabelen:

export KUBECONFIG=/path/to/kubeconfig

kubelogin convert-kubeconfig -l spn --pop-enabled --pop-claims "u=/ARM/ID/OF/CLUSTER"

export AAD_SERVICE_PRINCIPAL_CLIENT_ID=<SPN client ID>
export AAD_SERVICE_PRINCIPAL_CLIENT_SECRET=<SPN secret>

Voer deze kubectl-opdracht uit om knooppuntgegevens op te halen:

kubectl get nodes

Beheerde identiteit

Gebruik de verificatiemethode voor beheerde identiteiten voor toepassingen die verbinding maken met resources die ondersteuning bieden voor Microsoft Entra-verificatie. Voorbeelden hiervan zijn toegang tot Azure-resources, zoals een virtuele Azure-machine, een virtuele-machineschaalset of Azure Cloud Shell.

Standaard beheerde identiteit

In het volgende voorbeeld ziet u hoe u de standaard beheerde identiteit gebruikt:

export KUBECONFIG=/path/to/kubeconfig

kubelogin convert-kubeconfig -l msi

Voer deze kubectl-opdracht uit om knooppuntgegevens op te halen:

kubectl get nodes

Specifieke identiteit

In het volgende voorbeeld ziet u hoe u een beheerde identiteit gebruikt met een specifieke identiteit:

export KUBECONFIG=/path/to/kubeconfig

kubelogin convert-kubeconfig -l msi --client-id <msi-client-id>

Voer deze kubectl-opdracht uit om knooppuntgegevens op te halen:

kubectl get nodes

Workload-identiteit

De verificatiemethode voor workloadidentiteit 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:

  • 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 (JWT) voor een projected serviceaccount.
  • 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 ArgoCD, zonder service-principalreferenties op te slaan in de externe systemen. Zie het OIDC-federatievoorbeeld voor OIDC (OpenID Connect) vanuit GitHub.

In het volgende voorbeeld ziet u hoe u een workloadidentiteit gebruikt:

export KUBECONFIG=/path/to/kubeconfig

kubelogin convert-kubeconfig -l workloadidentity

Voer deze kubectl-opdracht uit om knooppuntgegevens op te halen:

kubectl get nodes

Kubelogin gebruiken met AKS

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

De AKS Microsoft Entra-servertoepassings-id die door de serverzijde wordt gebruikt, is 6dae42f8-4368-4678-94ff-3960e28e3630. Het toegangstoken dat toegang heeft tot AKS-clusters, moet worden uitgegeven voor deze toepassing. In de meeste kubelogin-verificatiemethoden moet u gebruiken --server-id met kubelogin get-token.

De AKS Microsoft Entra-clienttoepassings-id die kubelogin gebruikt voor het uitvoeren van openbare clientverificatie namens de gebruiker is 80faf920-1908-4b52-b5ef-a8e7bedfc67a. De clienttoepassings-id wordt gebruikt in apparaatcode en interactieve verificatiemethoden voor webbrowsers.

Gerelateerde inhoud