Il tuo team della piattaforma vuole rimuovere le credenziali a lunga durata per CI/CD e l'accesso in-cluster alle risorse Azure. GitHub Actions deve distribuire i modelli Bicep su Azure senza un client secret e i carichi di lavoro AKS devono accedere a Key Vault e Storage senza archiviare i segreti del service principal. Cosa dovresti configurare? Ogni risposta corretta presenta parte della soluzione.

La prima risposta corretta descrive come configurare GitHub Actions per l'autenticazione senza credenziali a lunga durata. Creando una registrazione dell'app in Entra ID con una credenziale federata che si fida dell'issuer OIDC di GitHub, si consente a GitHub Actions di scambiare un token OIDC con un token di accesso Azure AD. Questo elimina la necessità di client secret o service principal, migliorando la sicurezza. La seconda risposta corretta affronta l'accesso in-cluster alle risorse Azure senza segreti. Abilitando Azure AD Workload Identity su AKS e configurando un account di servizio Kubernetes mappato a un'app Entra ID tramite una credenziale di identità federata, i pod possono ottenere automaticamente token Azure AD per accedere a Key Vault e Storage, eliminando la necessità di archiviare credenziali nei pod. Le opzioni errate propongono soluzioni meno sicure o deprecate. L'uso di PAT di GitHub o az login --username/--password introduce credenziali a lunga durata. AAD Pod Identity è un approccio legacy e non è consigliato per i nuovi cluster. L'uso di certificati montati come segreti di Kubernetes, sebbene migliore dei segreti, richiede la gestione dei certificati e non è l'approccio più moderno e senza segreti offerto da Workload Identity.