Risoluzione dei problemi di 'Access Denied' e autenticazione in AWS CLI

Access Denied in AWS CLI è frustrante perché il messaggio spesso nomina la chiamata API fallita ma non la riga della policy che l'ha causata. Questi problemi sono quasi sempre radicati in policy di Identity and Access Management (IAM) configurate male, credenziali temporanee scadute o una configurazione errata dell'ambiente CLI.

L'abitudine utile è suddividere il problema in due domande: chi sta chiamando la CLI e quale confine di policy impedisce a quell'identità di eseguire l'azione?

1. Diagnosi iniziale: identificazione del chiamante e delle credenziali

Prima di immergersi in un'analisi complessa delle policy, il primo passo è confermare in modo definitivo quale identità IAM sta usando AWS CLI e se tali credenziali sono ancora valide.

Verifica l'identità corrente: `sts get-caller-identity`

Questo è il comando diagnostico più critico. Ti dice esattamente quale ARN utente, ARN ruolo o sessione di ruolo assunto sta eseguendo i successivi comandi AWS.

aws sts get-caller-identity

Output previsto:

{
    "UserId": "AIDAIAMUSERID",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/DevUser"
}

Se l'ARN restituito non corrisponde all'utente o al ruolo che ti aspetti, stai operando con il profilo AWS o le variabili d'ambiente sbagliati.

Verifica la configurazione del profilo e della regione

Assicurati che sia in uso il profilo AWS corretto, specificato tramite il flag --profile o impostato tramite la variabile d'ambiente AWS_PROFILE.

# Controlla le impostazioni configurate per il profilo predefinito
aws configure list

# Oppure controlla un profilo specifico
aws configure list --profile prod-admin

Se l'output non mostra alcuna regione o mostra una regione errata, le operazioni su risorse globali o servizi specifici di una regione (come bucket S3 o istanze EC2) potrebbero fallire, a volte risultando in un Access Denied se la risorsa non viene trovata dove la CLI sta cercando.

Suggerimento: Se il comando sts get-caller-identity stesso fallisce con un errore di autenticazione, indica un problema fondamentale con le chiavi di accesso (potrebbero essere state eliminate, revocate o essere errate).

Gestione delle credenziali temporanee

Se stai usando un ruolo IAM (tramite STS AssumeRole), la CLI opera con credenziali temporanee che includono un SessionToken. Queste credenziali scadono dopo la durata configurata per la sessione, spesso un'ora nelle impostazioni predefinite. Sebbene AWS CLI di solito le aggiorni automaticamente quando provengono dalla catena di provider di credenziali standard, le configurazioni manuali possono fallire.

Sintomo: I comandi funzionano inizialmente, ma falliscono dopo un periodo di tempo prestabilito (ad esempio, 60 minuti) con un errore di autenticazione.

Soluzione: Se usi uno script personalizzato o un ambiente caricato manualmente, assicurati che il tuo metodo per assumere il ruolo includa un meccanismo per aggiornare le credenziali quando scadono.

2. Approfondimento sulle policy IAM e l'autorizzazione

Una volta confermata l'identità in uso, il passo successivo è determinare perché tale identità manca delle autorizzazioni necessarie. I fallimenti di autorizzazione AWS sono complessi perché più policy vengono valutate simultaneamente.

La gerarchia di valutazione delle policy IAM

Gli errori di autorizzazione si verificano tipicamente a causa di uno dei seguenti componenti della policy:

Rifiuto esplicito: Un'istruzione Deny esplicita in qualsiasi policy applicabile (Identità, Risorsa o Confine) ha sempre la precedenza su un'istruzione Allow.
Mancanza di Allow: Nessuna policy applicabile all'identità o alla risorsa concede l'azione specifica.

A. Policy basate sull'identità (Utenti e Ruoli)

Controlla le policy IAM allegate direttamente all'utente o al ruolo che viene assunto. Cerca:

Azioni mancanti: La policy elenca specificamente l'azione API necessaria (ad esempio, s3:ListBucket, ec2:DescribeInstances)?
Vincoli sulle risorse: La policy limita l'azione a risorse specifiche usando l'elemento Resource? Un errore comune è impostare Resource: "*" quando l'azione richiede un ARN specifico, o viceversa.
Condizioni: Ci sono condizioni (ad esempio, indirizzo IP di origine, ora del giorno, MFA richiesto) che non vengono soddisfatte?

B. Policy basate sulle risorse (S3, SQS, KMS)

Per servizi come S3 o KMS, la risorsa stessa ha una policy che stabilisce chi può accedervi. Per l'accesso tra account e per molti progetti specifici delle risorse, la policy della risorsa deve anche consentire il principale. Nello stesso account, l'interazione esatta dipende dal tipo di principale e dal servizio, quindi non dare per scontato che una policy di identità da sola spieghi ogni risultato.

Esempio: Tentare di accedere a un bucket S3 (Policy della risorsa) che ha un Deny esplicito per tutti gli utenti al di fuori di un endpoint VPC specifico risulterà in Access Denied, indipendentemente dalla policy IAM dell'utente.

C. Confini di autorizzazione e SCP

Se la tua organizzazione utilizza AWS Organizations, le Service Control Policies (SCP) definiscono le autorizzazioni massime consentite all'interno di un account. Allo stesso modo, i Confini di autorizzazione (Permission Boundaries) limitano le autorizzazioni massime che un'entità IAM può mai possedere.

Se la SCP o il Confine nega l'azione richiesta, l'operazione CLI fallirà, anche se la Policy di Identità concede l'autorizzazione.

Strumento pratico: Simulatore di policy IAM

Quando si risolvono problemi complessi, il Simulatore di policy IAM nella Console di gestione AWS è prezioso. Puoi testare un'azione specifica (ad esempio, s3:GetObject) su una risorsa specifica (ad esempio, arn:aws:s3:::my-bucket/key) e specificare l'entità IAM, aiutandoti a individuare esattamente quale istruzione della policy sta causando la negazione.

3. Scenari comuni di 'Access Denied' e soluzioni

Scenario 1: Accesso negato a S3 (Risorsa vs. Identità)

L'Access Denied di S3 è noto perché può derivare sia dalla Policy dell'Utente che dalla Policy del Bucket.

Causa	Diagnosi	Soluzione
Mancanza di Allow nella Policy del Bucket	`sts get-caller-identity` funziona, ma `aws s3 ls` fallisce.	Modifica la Policy del Bucket per consentire esplicitamente all'ARN chiamante di eseguire le azioni necessarie (`s3:ListBucket`, `s3:GetObject`).
Mancanza di autorizzazioni KMS Decrypt	L'accesso a oggetti crittografati fallisce (anche se la policy S3 lo consente).	Assicurati che l'entità IAM abbia le autorizzazioni per utilizzare la chiave KMS sottostante (`kms:Decrypt`) che ha crittografato l'oggetto.
Requester Pays	I tentativi di scaricare file di grandi dimensioni falliscono.	Se il bucket richiede `Requester Pays`, il comando CLI deve includere il flag `--request-payer requester`.

Scenario 2: Rifiuto implicito a causa di condizioni non soddisfatte

Molte policy utilizzano condizioni che impongono le migliori pratiche di sicurezza, come la richiesta di autenticazione multi-fattore (MFA).

Se la tua policy include una condizione come:

"Condition": {
    "Bool": {
        "aws:MultiFactorAuthPresent": "true"
    }
}

E tenti di eseguire un comando senza MFA autenticata, l'azione verrà implicitamente negata.

Soluzione: Per i comandi che richiedono MFA, devi prima creare una sessione STS autenticata con il tuo dispositivo MFA:

# 1. Ottieni credenziali temporanee usando il tuo token MFA
aws sts get-session-token --serial-number arn:aws:iam::123456:mfa/user --token-code 123456

# 2. Esporta l'AccessKeyId, SecretAccessKey e SessionToken risultanti come variabili d'ambiente per la tua sessione CLI.

Scenario 3: Regione mancante o errata

Sebbene non sia sempre un errore Access Denied, tentare di eseguire un'azione su una risorsa senza specificare la regione corretta porta spesso a fallimenti di autorizzazione o risorsa non trovata, specialmente quando si lavora con servizi regionali come EC2, DynamoDB o EKS.

Soluzione: Definisci esplicitamente la regione nel tuo comando o assicurati che il tuo profilo sia configurato correttamente.

aws ec2 describe-instances --region us-west-2

Controlli specifici per servizio che fanno risparmiare tempo

Gli errori IAM sono più facili da debug quando smetti di trattare AWS come un unico sistema di autorizzazioni. Ogni servizio aggiunge il proprio modello di risorsa e le proprie chiavi di condizione.

Per S3, separa le azioni a livello di bucket dalle azioni a livello di oggetto. s3:ListBucket usa l'ARN del bucket, mentre s3:GetObject e s3:PutObject usano ARN di oggetti sotto il bucket. Una policy che concede s3:GetObject su arn:aws:s3:::my-bucket è modellata in modo errato; l'accesso agli oggetti necessita di arn:aws:s3:::my-bucket/*. L'errore inverso è altrettanto comune per l'elenco.

Per KMS, controlla sia la policy della chiave che la policy IAM. Un ruolo può sembrare avere kms:Decrypt, ma se la policy della chiave non consente quel percorso del ruolo, la decifratura fallisce comunque. Questo si verifica quando si scaricano oggetti S3 crittografati, si estraggono snapshot EBS crittografati o si leggono segreti che utilizzano una chiave gestita dal cliente.

Per ECR, il login Docker e il pull delle immagini richiedono l'allineamento di più servizi. L'identità CLI potrebbe aver bisogno di ecr:GetAuthorizationToken, e la policy del repository potrebbe dover consentire azioni di pull se il repository è condiviso tra account. Se il ruolo del nodo del cluster sta eseguendo il pull dell'immagine, il debug con il tuo profilo amministratore personale dimostra ben poco; testa come il ruolo del nodo o il ruolo di esecuzione dell'attività.

Per i flussi di lavoro assume-role di STS, guarda entrambi i lati della relazione di fiducia. Il chiamante necessita dell'autorizzazione per chiamare sts:AssumeRole, e la policy di fiducia del ruolo di destinazione deve fidarsi del chiamante. Se nella policy di fiducia è presente un ID esterno o una condizione MFA, il comando assume-role deve soddisfarla.

La precedenza dell'ambiente può ingannare utenti esperti

AWS CLI non legge solo ~/.aws/credentials. Esamina una catena di provider di credenziali che può includere flag della riga di comando, variabili d'ambiente, profili nominativi, voci della cache SSO, token di identità web, metadati EC2 o ECS e assunzioni di ruolo configurate nel profilo. Ecco perché aws configure list è più utile che aprire un singolo file.

Un fallimento locale comune si presenta così: esegui export AWS_PROFILE=dev, poi successivamente incolli credenziali di produzione temporanee in AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY e AWS_SESSION_TOKEN. Le chiavi d'ambiente possono prendere il sopravvento, quindi i comandi che sembrano usare dev stanno in realtà usando la sessione esportata. In un terminale che è stato aperto tutto il giorno, esegui:

env | sort | grep '^AWS_'

Se cambi account spesso, usa schede terminali separate, un helper per le credenziali o script wrapper che stampano l'identità del chiamante prima dei comandi distruttivi. La riga extra nell'output è più economica che cancellare dall'account sbagliato.

4. Riepilogo dei comandi diagnostici

Usa questa checklist di comandi per diagnosticare rapidamente la catena di fallimenti di autorizzazione:

Obiettivo	Comando	Scopo
Verifica identità	`aws sts get-caller-identity`	Conferma l'ARN che esegue il comando.
Verifica configurazione	`aws configure list`	Controlla le impostazioni del profilo, la regione e il formato di output.
Testa validità policy	(Usa il Simulatore di policy IAM)	Verifica se un'identità IAM può eseguire una specifica azione API su una risorsa.
Identifica negazioni policy	`aws cloudtrail lookup-events ...`	Usa CloudTrail per vedere il record esatto dell'evento in cui la valutazione della policy è fallita.

Un percorso di debug reale

Un buon primo passaggio si presenta così. Esegui di nuovo il comando che fallisce con il profilo e la regione scritti esplicitamente, anche se pensi che la tua shell sia già impostata:

AWS_PROFILE=prod-readonly aws s3 ls s3://example-audit-logs --region us-east-1
aws sts get-caller-identity --profile prod-readonly
aws configure list --profile prod-readonly

Se l'identità è sbagliata, fermati lì. Controlla AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_PROFILE e AWS_REGION nell'ambiente. Le credenziali d'ambiente possono avere la precedenza su un profilo e far sì che la CLI agisca come un ruolo che hai dimenticato di aver esportato in precedenza. In CI, stampa aws sts get-caller-identity vicino al passaggio che fallisce in modo che il log di build dimostri il ruolo utilizzato in fase di esecuzione.

Se l'identità è corretta, annota l'esatta azione API. I comandi di alto livello possono nasconderla. aws s3 cp potrebbe aver bisogno di s3:GetObject, s3:PutObject, s3:ListBucket, kms:Decrypt o kms:GenerateDataKey a seconda della direzione, della crittografia e se la CLI deve ispezionare il bucket. Quando il messaggio di errore include AccessDenied ma non l'azione, CloudTrail di solito ti fornisce il nome dell'evento e la risorsa.

Per S3, controlla la policy del bucket, la proprietà dell'oggetto, le impostazioni di blocco dell'accesso pubblico, la policy dell'endpoint VPC e la policy della chiave KMS. Per gli oggetti crittografati con KMS, un'autorizzazione S3 non è sufficiente; il chiamante necessita anche dell'autorizzazione KMS pertinente e la policy della chiave deve consentire il percorso del principale. Per le organizzazioni, controlla le SCP prima di modificare le policy di identità. Una SCP non può concedere l'accesso, ma può limitare ciò che qualsiasi principale nell'account può fare.

La prevenzione è per lo più igiene noiosa: credenziali di ruolo di breve durata, profili con nomi chiari, policy con privilegi minimi testate contro l'ARN reale e CloudTrail abilitato dove gli ingegneri possono effettivamente interrogarlo. La soluzione migliore non è un Action: "*" più ampio; è trovare l'azione mancante o la condizione di negazione che corrisponde alla richiesta.