Usare provider di identità esterni con l'autenticazione strutturata di AKS (anteprima)

Il servizio Azure Kubernetes supporta l'autenticazione strutturata, che consente di configurare provider di identità esterni per l'autenticazione degli utenti nel server API Kubernetes. Questa funzionalità si basa sulla configurazione strutturata di autenticazione upstream di Kubernetes. AKS implementa questa funzionalità tramite autenticatori JSON Web Token (JWT) che convalidano i token dai provider di identità esterni secondo la tua configurazione. Con l'autenticazione strutturata, le organizzazioni possono integrare AKS con la loro infrastruttura di identità esistente, oltre a Microsoft Entra ID.

Questo articolo offre una panoramica di come usare l'autenticazione strutturata di AKS con provider di identità esterni, come i concetti chiave, le considerazioni di sicurezza e i passaggi successivi per la configurazione.

Vantaggi dell'autenticazione del provider di identità esterna

L'autenticazione strutturata estende il servizio Azure Kubernetes oltre all'integrazione tradizionale di Microsoft Entra ID, supportando provider di identità OpenID Connect (OIDC) standard del settore. Questa funzionalità consente di:

• Autenticare gli utenti con provider di identità esterni come Google, GitHub o qualsiasi provider conforme a OIDC.
• Gestire la gestione centralizzata delle identità nell'organizzazione.
• Implementare regole di convalida delle claim personalizzate e di mapping degli utenti.
• Supportare più provider di identità contemporaneamente in un singolo cluster.

Flusso di autenticazione del provider di identità esterno

Quando un utente tenta di accedere al server API Kubernetes usando l'autenticazione strutturata con un provider di identità esterno, il flusso di autenticazione e autorizzazione è il seguente:

• Autenticazione: i passaggi seguenti convalidano l'identità dell'utente:
  • Presentazione del token: l'utente presenta un token JWT dal provider di identità configurato.
  • Convalida del token: il server API convalida la firma, l'autorità di certificazione, il gruppo di destinatari e la scadenza del token.
  • Elaborazione delle attestazioni: le regole di convalida delle attestazioni personalizzate vengono applicate per garantire che il token soddisfi i requisiti.
  • Mapping degli utenti: le attestazioni vengono mappate all'identità utente di Kubernetes (nome utente, gruppi e attributi aggiuntivi).
• Autorizzazione: Il controllo degli accessi basato sui ruoli standard di Kubernetes (RBAC) determina quali azioni l'utente autenticato può eseguire.

Provider di identità supportati

Anche se l'autenticazione strutturata di AKS consente qualsiasi provider di identità conforme a OIDC, i provider più diffusi includono:

• GitHub: eseguire l'autenticazione usando le identità GitHub o GitHub Actions.
• Google OAuth 2.0: usare gli account Google per l'autenticazione.
• Provider OIDC generici: ogni provider che implementa gli standard OIDC.
• Soluzioni di gestione delle identità personalizzate: implementazioni OIDC specifiche dell'organizzazione.

Requisiti per i provider di identità esterni

Per usare l'autenticazione strutturata di AKS (Azure Kubernetes Service), i provider di identità esterni devono soddisfare i requisiti seguenti:

• Supportare gli standard OIDC.
• Fornire endpoint di individuazione OIDC accessibili pubblicamente.
• Rilasciare token JWT con attestazioni appropriate.
• Essere accessibile dai nodi del cluster AKS per la convalida dei token.

Autenticatori JWT per l'autenticazione strutturata di AKS

Un autenticatore JWT è un oggetto di configurazione che definisce il modo in cui AKS convalida ed elabora i token da un provider di identità esterno. Ad esempio, il servizio Azure Kubernetes prevede un token ID (JWT), la cui attestazione aud (pubblico) corrisponda al valore del pubblico configurato per l'app di autenticazione, ad esempio "my-api" o un ID client OAuth. Ogni autenticatore JWT include i componenti seguenti:

• Configurazione dell'emittente: specifica l'URL dell'emittente OIDC e i valori previsti per l'audience per i token.
• Regole di convalida attestazioni: usa espressioni CEL (Common Expression Language) per applicare la logica di convalida personalizzata alle attestazioni del token.
• Mapping delle attestazioni: definisce come le attestazioni JWT vengono collegate agli attributi utente di Kubernetes, come nome utente, gruppi e campi aggiuntivi.
• Regole di convalida utente: applica logica di convalida aggiuntiva dopo il mapping delle attestazioni per limitare o consentire ulteriormente l'accesso.

Espressioni CEL per la convalida e il mapping delle attestazioni

L'autenticazione strutturata usa espressioni CEL per la convalida e il mapping flessibile delle attestazioni. CEL offre un ambiente sandbox sicuro per la valutazione della logica personalizzata rispetto alle attestazioni JWT.

Espressioni CEL di esempio:

// 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)

Procedure consigliate per la sicurezza

Tenere presenti le procedure consigliate seguenti quando si usano provider di identità esterni con l'autenticazione per il servizio Azure Kubernetes.

• Usare la convalida avanzata delle attestazioni: implementare regole di convalida complete per garantire che vengano accettati solo i token autorizzati.
• Limitare l'ambito del token: configurare il provider di identità per rilasciare token con attestazioni minime necessarie.
• Rotazione regolare: ruotare regolarmente i segreti e i certificati client.
• Monitorare l'accesso: abilitare i log delle risorse e attivare kube-apiserver i log per esaminare eventuali problemi con gli autenticatori JWT configurati e tenere traccia degli eventi di autenticazione.
• Configurazioni di test: convalidare prima la configurazione dell'autenticatore JWT in un ambiente non di produzione.

Considerazioni sulla sicurezza

Quando si utilizzano provider di identità esterni con l'autenticazione strutturata in AKS, tenere presenti le seguenti considerazioni sulla sicurezza:

• Requisiti di prefisso: tutti i nomi utente e i gruppi mappati tramite l'autenticazione strutturata devono essere preceduti aks:jwt: da per evitare conflitti con altri metodi di autenticazione e account di sistema.
• Accesso alla rete: gli endpoint del provider di identità devono essere accessibili da:
  • Nodi del cluster AKS per la convalida dei token.
  • Sistemi client per l'acquisizione di token.
  • Tutti i percorsi di rete coinvolti nel flusso di autenticazione.
• Livelli di convalida: l'autenticazione strutturata offre più livelli di convalida:
  • La convalida della firma del token garantisce l'autenticità del token.
  • La convalida dell'attestazione standard verifica l'autorità emittente, il gruppo di destinatari e la scadenza.
  • La convalida dell'attestazione personalizzata applica i requisiti specifici della tua organizzazione.
  • Controlli finali della convalida utente dopo il mapping delle asserzioni.

Contenuti correlati

Per altre informazioni sull'autenticazione strutturata e sulle funzionalità correlate, vedere le risorse seguenti:

• Configurare l'autenticazione strutturata per AKS
• Configurazione dell'autenticazione strutturata di Kubernetes
• Espressioni CEL in Kubernetes
• Specifica OpenID Connect