Un'applicazione su EC2 utilizzava in precedenza le chiavi di accesso dell'utente IAM memorizzate nelle variabili d'ambiente per chiamare DynamoDB tramite boto. Lo sviluppatore ha collegato un ruolo di istanza con le stesse autorizzazioni e quindi ha eliminato l'utente IAM. Dopo il riavvio, i log dell'applicazione mostrano AccessDeniedException, ma lo sviluppatore può eseguire i comandi CLI di DynamoDB utilizzando il proprio account personale sul server. Qual è la causa PIÙ probabile dell'eccezione?

La causa più probabile è che l'applicazione sta ancora utilizzando le credenziali dalle variabili d'ambiente, che sono state disabilitate con l'eliminazione dell'utente IAM. Quando si configura un ruolo di istanza, l'applicazione deve essere configurata per recuperare le credenziali dal servizio di metadati dell'istanza (IMDS). Boto3 (e altri SDK AWS) cercano le credenziali in un ordine specifico, dando priorità alle variabili d'ambiente rispetto ai ruoli di istanza. Se le variabili d'ambiente non sono state rimosse o sovrascritte, l'applicazione continuerà a tentare di utilizzarle, risultando in un'eccezione AccessDeniedException. Lo sviluppatore può eseguire i comandi CLI perché la CLI utilizza le credenziali del suo account personale, non quelle dell'applicazione. Le policy IAM si propagano rapidamente, quindi la propagazione non è il problema. L'SDK AWS supporta pienamente i ruoli di istanza. Il security group non è rilevante in questo caso, poiché l'accesso a http://169.254.169.254 è necessario per recuperare le credenziali del ruolo di istanza, ma il problema qui è l'utilizzo di credenziali obsolete.