Kubelogin gebruiken om gebruikers te verifiëren in Azure Kubernetes Service
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
- Meer informatie over het integreren van AKS met Microsoft Entra ID in het door AKS beheerde Microsoft Entra ID-integratieartikel .
- Zie Een beheerde identiteit gebruiken in AKS om aan de slag te gaan met beheerde identiteiten in AKS.
- Zie Een workloadidentiteit in AKS gebruiken om aan de slag te gaan met workloadidentiteiten in AKS.
Azure Kubernetes Service