Ruoli IAM per gli account di servizio (IRSA)

Quando un pod in esecuzione in EKS deve chiamare un'API AWS, ad esempio per leggere da S3 o scrivere in DynamoDB, ha bisogno di credenziali AWS. L'approccio più semplice consiste nel creare un utente IAM e impostare le relative chiavi di accesso come variabili d'ambiente. Questa soluzione non è sicura e viola il principio del privilegio minimo, perché tutti i pod sullo stesso nodo condividono le credenziali. IAM Roles for Service Accounts (IRSA) risolve il problema associando ruoli IAM con autorizzazioni granulari direttamente agli account di servizio Kubernetes.

IRSA funziona tramite la federazione OpenID Connect (OIDC). EKS crea un provider OIDC per il cluster. Quando un pod fa riferimento a un account di servizio annotato con un ARN di ruolo IAM, EKS inserisce nel pod un token proiettato dell'account di servizio e firmato. L'AWS SDK nel pod scambia questo token con credenziali AWS temporanee utilizzando l'API AssumeRoleWithWebIdentity di AWS STS, senza bisogno di chiavi a lunga durata.

Prima di utilizzare IRSA, deve associare l'issuer OIDC di EKS come provider di identità attendibile nel proprio account AWS. In questo modo viene creata una risorsa provider OIDC IAM che AWS STS riconoscerà. Il comando eksctl gestisce automaticamente questa operazione. Dopo la creazione, può verificarla nella console IAM, nella sezione Identity Providers.

Il ruolo IAM per IRSA deve avere una trust policy che consenta al provider OIDC di assumerlo, limitandone l'ambito a uno specifico namespace Kubernetes e a uno specifico account di servizio. La condizione utilizza il claim sub nel token OIDC, impostato su system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME. In questo modo solo i pod che utilizzano quello specifico account di servizio possono assumere il ruolo, non un pod qualsiasi del cluster.

Crei un ServiceAccount Kubernetes nel namespace di destinazione e lo annoti con l'ARN del ruolo IAM. Quando un pod fa riferimento a questo account di servizio, EKS inserisce automaticamente il token OIDC e due variabili d'ambiente (AWS_WEB_IDENTITY_TOKEN_FILE e AWS_ROLE_ARN). L'AWS SDK le rileva automaticamente e chiama STS per ottenere credenziali temporanee: non sono necessarie modifiche al codice dell'applicazione.

Nella specifica del pod o del deployment, imposti serviceAccountName sull'account di servizio annotato. Quando EKS pianifica il pod, monta automaticamente il token OIDC in /var/run/secrets/eks.amazonaws.com/serviceaccount/token e imposta le variabili d'ambiente necessarie. Qualsiasi chiamata all'AWS SDK all'interno del pod utilizzerà in modo trasparente le credenziali del ruolo IAM associato, senza alcuna configurazione esplicita delle credenziali.

Con un ruolo IAM del nodo, ogni pod su un nodo eredita le stesse autorizzazioni: un pod compromesso può accedere a tutti i servizi AWS a cui il nodo può accedere. Con IRSA, ogni pod, tramite il proprio account di servizio, assume solo il ruolo di cui ha bisogno. Questo applica il principio del privilegio minimo a livello di pod e limita l'impatto di qualsiasi incidente di sicurezza. AWS consiglia IRSA anziché i ruoli a livello di nodo per tutti i nuovi deployment EKS.

eksctl può creare l'associazione OIDC, il ruolo IAM, la trust policy e l'annotazione Kubernetes del ServiceAccount con un singolo comando che utilizza create iamserviceaccount. Questo è il modo più semplice per configurare IRSA senza scrivere manualmente il JSON della trust policy. È sufficiente specificare il namespace, il nome dell'account di servizio e l'ARN della policy IAM da associare: eksctl gestirà il resto.

Molti add-on e controller EKS richiedono IRSA per funzionare: Cluster Autoscaler necessita dell'autorizzazione a chiamare l'API EC2 Auto Scaling, AWS Load Balancer Controller necessita dell'autorizzazione a creare e gestire risorse ELB, external-dns necessita dell'accesso in scrittura a Route 53 e il driver EBS CSI necessita dell'autorizzazione a creare e collegare volumi EBS. Utilizzi sempre IRSA per questi componenti di sistema: non conceda mai queste autorizzazioni a livello del ruolo IAM del nodo.

I token IRSA hanno una durata breve e vengono ruotati automaticamente dal controller di proiezione dei token Kubernetes prima della scadenza. Il pubblico predefinito del token è sts.amazonaws.com e la scadenza è di 24 ore, ma il controller li aggiorna quando è trascorso l'80% della loro durata. Anche le credenziali AWS STS ottenute tramite IRSA sono temporanee, in genere con durata di 1 ora. Questa rotazione automatica elimina l'onere di ruotare le credenziali associato alle chiavi di accesso IAM a lunga durata.

Ogni volta che un pod assume un ruolo IAM tramite IRSA, AWS CloudTrail registra un evento AssumeRoleWithWebIdentity. L'evento include l'ARN del ruolo assunto, il subject del token OIDC (system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT) e l'indirizzo IP di origine. Questo fornisce un audit trail completo dei pod che hanno acceduto ai servizi AWS, dei servizi utilizzati e del momento dell'accesso, un elemento fondamentale per la conformità e l'analisi degli incidenti negli ambienti regolamentati.

Verifichi la Sua comprensione dei concetti di AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione ha imparato che IRSA utilizza la federazione OIDC per scambiare i token degli account di servizio Kubernetes con credenziali AWS temporanee, che le trust policy dei ruoli IAM limitano l'accesso a uno specifico namespace e account di servizio e che IRSA offre il privilegio minimo per pod, molto più efficacemente rispetto ai ruoli IAM a livello di nodo. Ora esamineremo le metriche, i namespace e le dimensioni di CloudWatch per monitorare le risorse AWS.