Externe id-providers gebruiken met gestructureerde AKS-verificatie (preview)

Azure Kubernetes Service (AKS) ondersteunt gestructureerde verificatie, waarmee u externe id-providers kunt configureren voor het verifiëren van gebruikers bij de Kubernetes-API-server. Deze functie is gebaseerd op de upstream kubernetes-configuratie voor gestructureerde verificatie. AKS implementeert deze functionaliteit via JSON Web Token (JWT) authenticators waarmee tokens van externe id-providers worden gevalideerd op basis van uw configuratie. Met gestructureerde verificatie kunnen organisaties AKS integreren met hun bestaande identiteitsinfrastructuur buiten Microsoft Entra ID.

Dit artikel bevat een overzicht van het gebruik van externe id-providers met gestructureerde AKS-verificatie, waaronder belangrijke concepten, beveiligingsoverwegingen en volgende stappen voor configuratie.

Voordelen van verificatie van externe id-provider

Gestructureerde authenticatie breidt AKS verder uit dan de traditionele Microsoft Entra ID-integratie door ondersteuning te bieden voor industrie-standaard OpenID Connect-identiteitsproviders (OIDC). Met deze functie kunt u:

• Verifieer gebruikers met externe id-providers, zoals Google, GitHub of een OIDC-compatibele provider.
• Gecentraliseerd identiteitsbeheer in uw organisatie onderhouden.
• Implementeer aangepaste claimvalidatie- en gebruikerstoewijzingsregels.
• Ondersteuning voor meerdere id-providers tegelijk op één cluster.

Authenticatiestroom van externe identiteitsprovider

Wanneer een gebruiker toegang probeert te krijgen tot de Kubernetes-API-server met behulp van gestructureerde verificatie met een externe id-provider, is de verificatie- en autorisatiestroom als volgt:

• Verificatie: Met de volgende stappen valideert u de identiteit van de gebruiker:
  • Tokenpresentatie: De gebruiker presenteert een JWT-token van de geconfigureerde id-provider.
  • Tokenvalidatie: De API-server valideert de handtekening, verlener, doelgroep en vervaldatum van het token.
  • Claimverwerking: aangepaste claimvalidatieregels worden toegepast om ervoor te zorgen dat het token voldoet aan uw vereisten.
  • Gebruikerstoewijzing: claims worden toegewezen aan kubernetes-gebruikersidentiteit (gebruikersnaam, groepen en extra kenmerken).
• Autorisatie: Standard Kubernetes Role-Based Access Control (RBAC) bepaalt welke acties de geverifieerde gebruiker kan uitvoeren.

Ondersteunde id-providers

Hoewel gestructureerde AKS-verificatie elke id-provider die compatibel is met OIDC toestaat, omvatten algemene providers:

• GitHub: verifiëren met behulp van GitHub-identiteiten of GitHub Actions.
• Google OAuth 2.0: Google-accounts gebruiken voor verificatie.
• Algemene OIDC-providers: elke provider die OIDC-standaarden implementeert.
• Aangepaste identiteitsoplossingen: organisatiespecifieke OIDC-implementaties.

Vereisten voor externe id-providers

Externe id-providers moeten voldoen aan de volgende vereisten om te kunnen werken met gestructureerde AKS-verificatie:

• Ondersteuning voor OIDC-standaarden.
• Geef openbaar toegankelijke OIDC-detectie-eindpunten op.
• JWT-tokens uitgeven met de juiste claims.
• Toegankelijk zijn vanaf AKS-clusterknooppunten voor tokenvalidatie.

JWT-verificators voor gestructureerde AKS-verificatie

Een JWT Authenticator is een configuratieobject dat definieert hoe AKS tokens van een externe id-provider valideert en verwerkt. AKS verwacht bijvoorbeeld een id-token (JWT) waarvan aud de claim (doelgroep) overeenkomt met de doelgroepwaarde die u voor de verificator configureert, zoals "my-api", of een OAuth-client-id. Elke JWT-verificator bevat de volgende onderdelen:

• Configuratie van verlener: hiermee geeft u de URL van de OIDC-verlener en de verwachte doelgroepwaarden voor tokens op.
• Claimvalidatieregels: maakt gebruik van CEL-expressies (Common Expression Language) om aangepaste validatielogica af te dwingen voor tokenclaims.
• Claimtoewijzingen: Definieert hoe JWT-claims worden toegewezen aan Kubernetes-gebruikerskenmerken, zoals gebruikersnaam, groepen en extra velden.
• Gebruikersvalidatieregels: past extra validatielogica toe na claimtoewijzing om de toegang verder te beperken of toe te staan.

CEL-expressies voor claimvalidatie en mapping

Gestructureerde verificatie gebruikt CEL-expressies voor flexibele claimvalidatie en -toewijzing. CEL biedt een beveiligde sandbox-omgeving voor het evalueren van aangepaste logica op basis van JWT-claims.

Voorbeeld van CEL-expressies:

// Validate that the 'sub' claim exists
has(claims.sub)

// Map username with AKS prefix
'aks:jwt:' + claims.sub

// Map groups from comma-separated string
claims.groups.split(',').map(g, 'aks:jwt:' + g)

// Conditional mapping based on claim verification
'aks:jwt:' + (claims.email_verified ? claims.email : claims.sub)

Aanbevolen procedures voor beveiliging

Houd rekening met de volgende aanbevolen beveiligingsprocedures bij het gebruik van externe id-providers met gestructureerde AKS-verificatie:

• Gebruik krachtige claimvalidatie: implementeer uitgebreide validatieregels om ervoor te zorgen dat alleen geautoriseerde tokens worden geaccepteerd.
• Bereik van token beperken: configureer uw id-provider om tokens uit te geven met minimale benodigde claims.
• Regelmatige rotatie: clientgeheimen en certificaten regelmatig roteren.
• Toegang bewaken: schakel resourcelogboeken in en schakel logboeken in kube-apiserver om mogelijke problemen met de geconfigureerde JWT-verificators te inspecteren en verificatiegebeurtenissen bij te houden.
• Testconfiguraties: valideer eerst uw JWT Authenticator-configuratie in een niet-productieomgeving.

Beveiligingsoverwegingen

Houd rekening met de volgende beveiligingsoverwegingen bij het gebruik van externe id-providers met gestructureerde AKS-verificatie:

• Vereisten voor voorvoegsel: alle gebruikersnamen en groepen die zijn toegewezen via gestructureerde verificatie, moeten worden voorafgegaan door aks:jwt: conflicten met andere verificatiemethoden en systeemaccounts te voorkomen.
• Netwerktoegang: eindpunten van id-providers moeten toegankelijk zijn vanuit:
  • AKS-clusterknooppunten voor tokenvalidatie.
  • Clientsystemen voor het verkrijgen van tokens.
  • Alle netwerkpaden die betrokken zijn bij de verificatiestroom.
• Validatielagen: Gestructureerde verificatie biedt meerdere validatielagen:
  • Validatie van tokenhandtekening zorgt voor echtheid van tokens.
  • Standaardclaimvalidatie controleert de uitgever, doelgroep en vervaldatum.
  • Aangepaste claimvalidatie past de specifieke vereisten van uw organisatie toe.
  • Gebruikersvalidatie eindcontroles na claimtoewijzing.

Verwante inhoud

Zie de volgende bronnen voor meer informatie over gestructureerde verificatie en gerelateerde functies:

• Gestructureerde verificatie configureren voor AKS
• Configuratie van gestructureerde Kubernetes-verificatie
• CEL-expressies in Kubernetes
• OpenID Connect-specificatie