Il paradosso dell'autenticazione senza segreti
Le managed identity promettono di eliminare segreti e password, ma non eliminano i controlli di autorizzazione e la visibilità sul runtime. È comune vedere un servizio in sviluppo risolvere correttamente il token, mentre in produzione il medesimo workload non ottiene accesso al database o allo storage.
Controlli di base
- Identity assegnata al servizio — verifica che la VM, App Service, AKS pod o altro compute abbia davvero la managed identity abilitata e autorizzata.
- Tipo di identity — system-assigned e user-assigned funzionano diversamente. Quando un servizio viene ricreato, la system-assigned può cambiare e perdere permessi; per workload condivisi la user-assigned è più stabile.
- Permessi RBAC — controlla che il service principal dell'identity abbia role assignment sul target corretto e che non ci siano condizioni MFA o policy conditional che bloccano l'accesso.
- Endpoint di metadata — nel runtime Azure il servizio deve poter raggiungere il metadata endpoint locale (169.254.169.254) e ricevere risposta da
/metadata/identity/endpoint. Se il container ha networking isolato, il token non viene richiesto.
Pattern ricorrenti
Gli errori più frequenti sono: App Service deployato su uno slot che non ha ereditato l'identity, AKS pod che usa il service account sbagliato, VM con extension azurerm non aggiornata, e policy di sicurezza che blocca la chiamata al metadata endpoint. Anche l'uso di librerie non aggiornate di Azure.Identity può cambiare il comportamento tra locale e cloud.
Come stabilizzare il runtime
La regola più pratica è separare il deployment dall'autorizzazione: crea e verifica l'identity prima del primo deploy, poi applica RBAC con auditing. In produzione, monitorare i failed requests dall'identity endpoint e validare il token con una chiamata di sanity check sul dependency target aiuta a evitare failure a freddo.