Ruoli IAM per gli account di servizio - Amazon EKS
Informazioni di base su IAM, Kubernetes e OpenID Connect (OIDC)

Contribuisci a migliorare questa pagina

Per contribuire a questa guida per l’utente, seleziona il link Edit this page on GitHub che si trova nel riquadro destro di ogni pagina.

Ruoli IAM per gli account di servizio

Le applicazioni nei container di un pod possono utilizzare un SDK AWS o la CLI AWS per effettuare richieste API ai servizi AWS utilizzando le autorizzazioni di AWS Identity and Access Management (IAM). Le applicazioni devono firmare le proprie richieste API AWS con le credenziali AWS. I ruoli IAM per gli account di servizio (IRSA) forniscono la possibilità di gestire le credenziali per le applicazioni, analogamente al modo in cui i profili di istanza Amazon EC2 forniscono le credenziali alle istanze Amazon EC2. Invece di creare e distribuire le tue credenziali AWS ai container o utilizzare il ruolo dell’istanza Amazon EC2, associ un ruolo IAM a un account di servizio Kubernetes e configuri i tuoi pod per utilizzare l’account di servizio. Non è possibile utilizzare i ruoli IAM per gli account di servizio con i cluster locali per Amazon EKS su AWS Outposts.

La caratteristica dei ruoli IAM per gli account di servizio offre i seguenti vantaggi:

  • Privilegio minimo: è possibile definire l’ambito delle autorizzazioni IAM per un account di servizio; solo i pod che utilizzano tale account avranno accesso alle autorizzazioni definite. Questa caratteristica elimina anche la necessità di soluzioni di terze parti, ad esempio kiam o kube2iam.

  • Isolamento delle credenziali: quando l’accesso al servizio di metadati di istanza (IMDS)di Amazon EC2 è limitato, un container del pod può recuperare solo le credenziali per il ruolo IAM associato all’account del servizio che utilizza. Un container non ha mai accesso alle credenziali utilizzate da altri container in altri pod. Se IMDS non è soggetto a restrizioni, i container del pod hanno accesso anche al ruolo IAM del nodo Amazon EKS potrebbero essere in grado di accedere alle credenziali dei ruoli IAM di altri pod sullo stesso nodo. Per ulteriori informazioni, consulta Limitazione dell’accesso al profilo dell’istanza assegnato al nodo worker.

Nota

I pod configurati con hostNetwork: true avranno sempre accesso IMDS, ma gli AWS SDK e la CLI utilizzeranno le credenziali IRSA quando abilitati.

  • Possibilità di effettuare controlli: accesso e registrazione degli eventi sono disponibili tramite AWS CloudTrail per garantire controlli retrospettivi.

Importante

I container non costituiscono un limite di sicurezza e l’uso dei ruoli IAM per gli account di servizio non cambia questa situazione. I pod assegnati allo stesso nodo condivideranno un kernel e potenzialmente altre risorse a seconda della configurazione del pod. Sebbene i pod in esecuzione su nodi separati siano isolati a livello di elaborazione, esistono applicazioni di nodo che dispongono di autorizzazioni aggiuntive nell’API Kubernetes oltre all’ambito di una singola istanza. Alcuni esempi sono kubelet, kube-proxy, i driver di archiviazione CSI o le tue applicazioni Kubernetes.

Abilita i ruoli IAM per gli account di servizio completando le seguenti procedure:

  1. Creazione di un provider OIDC IAM per il cluster: questa operazione viene completata solo una sola volta per cluster.

    Nota

    Se è stato abilitato l’endpoint VPC EKS, non è possibile accedere all’endpoint del servizio OIDC EKS dall’interno di tale VPC. Di conseguenza, le operazioni come la creazione di un provider OIDC con eksctl nel VPC non funzioneranno e comporteranno un timeout durante il tentativo di richiesta di https://oidc.eks.region.amazonaws.com. Segue un messaggio di errore di esempio:

    server cant find oidc.eks.region.amazonaws.com: NXDOMAIN

    Per completare questo passaggio, è possibile eseguire il comando all’esterno del VPC, ad esempio in AWS CloudShell o su un computer connesso a Internet. In alternativa, puoi creare un resolver condizionale di tipo split-horizon nel VPC, come il risolutore Route 53, per utilizzare un resolver diverso per l’URL emittente OIDC e non utilizzare il DNS VPC. Per un esempio di inoltro condizionale in CoreDNS, consulta Amazon EKS feature request su GitHub.

  2. Assegna i ruoli IAM agli account del servizio Kubernetes: completa questa procedura per ogni set univoco di autorizzazioni che desideri abbia un’applicazione.

  3. Configura i pod per utilizzare un account del servizio Kubernetes: completa questa procedura per ogni pod che deve accedere ai servizi AWS.

  4. Utilizza IRSA con SDK AWS: verifica che il carico di lavoro utilizzi un SDK AWS di una versione supportata e che utilizzi la catena di credenziali predefinita.

Informazioni di base su IAM, Kubernetes e OpenID Connect (OIDC)

Nel 2014, AWS Identity and Access Management ha aggiunto il supporto per le identità federate mediante OpenID Connect (OIDC). Questa caratteristica consente di autenticare le chiamate API AWS con provider di identità supportati e ricevere un token Web JSON OIDC (JWT) valido. É possibile passare questo token all’operazione API AssumeRoleWithWebIdentity di AWS STS e ricevere credenziali temporanee per il ruolo IAM. È possibile utilizzare queste credenziali per interagire con qualsiasi servizio AWS, tra cui Amazon S3 e DynamoDB.

Ogni token JWT è firmato da una coppia di chiavi di firma. Le chiavi vengono fornite dal provider OIDC gestito da Amazon EKS e la chiave privata ruota ogni 7 giorni. Amazon EKS conserva le chiavi pubbliche fino alla loro scadenza. Se si connettono client OIDC esterni, si tenga presente che è necessario aggiornare le chiavi di firma prima della scadenza della chiave pubblica. Scopri Fetch signing keys to validate OIDC tokens.

Kubernetes utilizza da tempo gli account di servizio come sistema di identità interno. I pod possono eseguire l’autenticazione con il server API Kubernetes utilizzando un token con montaggio automatico (che è un token JWT non OIDC) che solo il server API Kubernetes può convalidare. Questi token legacy dell’account di servizio non hanno scadenza e la rotazione della chiave di firma è un processo difficile. Nella versione 1.12 di Kubernetes, è stato aggiunto il supporto per una nuova funzionalità ProjectedServiceAccountToken. Questa funzionalità è un token Web OIDC JSON che contiene anche l’identità dell’account del servizio e supporta un pubblico configurabile.

Amazon EKS ora ospita un endpoint di rilevamento OIDC pubblico per ogni cluster, contenente le chiavi di firma per i token Web ProjectedServiceAccountToken JSON, in modo che i sistemi esterni, ad esempio IAM, possano convalidare e accettare i token OIDC emessi da Kubernetes.