Un'azienda esegue un'applicazione su un cluster Amazon Elastic Kubernetes Service (Amazon EKS) su istanze Amazon EC2. L'applicazione ha un'interfaccia utente che utilizza Amazon DynamoDB e servizi dati che utilizzano Amazon S3. L'azienda deve garantire che i Pod EKS per l'interfaccia utente possano accedere solo ad Amazon DynamoDB e che i Pod EKS per i servizi dati possano accedere solo ad Amazon S3. L'azienda utilizza AWS Identity and Access Management (IAM). Quale soluzione soddisfa questi requisiti?

La soluzione corretta è creare account di servizio Kubernetes separati (Service Accounts) per l'interfaccia utente e i servizi dati, ciascuno configurato per assumere un ruolo IAM specifico. Questo approccio, noto come IAM Roles for Service Accounts (IRSA), consente di assegnare autorizzazioni IAM granulari direttamente ai Pod EKS. Collegando una policy con accesso a DynamoDB all'account di servizio dell'interfaccia utente e una policy con accesso a S3 all'account di servizio dei servizi dati, si garantisce che ogni tipo di Pod abbia solo le autorizzazioni necessarie, aderendo al principio del privilegio minimo. Le altre opzioni sono meno efficaci o errate: Collegare le policy IAM al profilo dell'istanza EC2 concederebbe a tutti i Pod in esecuzione su quell'istanza le stesse autorizzazioni, violando il principio del privilegio minimo. L'RBAC di Kubernetes controlla l'accesso alle risorse di Kubernetes, non alle risorse AWS. Non è possibile collegare direttamente le policy IAM ai Pod EKS; è necessario utilizzare un meccanismo come IRSA. L'ultima opzione inverte le autorizzazioni, assegnando a S3 l'accesso all'interfaccia utente e a DynamoDB l'accesso ai servizi dati, il che è contrario ai requisiti.