Ruoli IAM per gli account di servizio

Applicazioni in un Podi contenitori possono utilizzare un AWS SDK o the AWS CLI per effettuare API richieste ai permessi Servizi AWS using AWS Identity and Access Management (IAM). Le applicazioni devono firmare le proprie AWS API richieste con AWS credenziali. IAMi ruoli per gli account di servizio offrono la possibilità di gestire le credenziali per le applicazioni, in modo simile al modo in cui i profili di EC2 istanza Amazon forniscono le credenziali alle istanze AmazonEC2. Invece di creare e distribuire AWS le tue credenziali ai contenitori o utilizzare il ruolo dell'EC2istanza Amazon, associ un IAM ruolo a Kubernetes account di servizio e configura il tuo Pods per utilizzare l'account di servizio. Non puoi utilizzare IAM i ruoli per gli account di servizio con cluster locali per EKS Amazon AWS Outposts attivi.

IAMi ruoli per gli account di servizio offrono i seguenti vantaggi:

• Privilegio minimo: è possibile definire l'ambito IAM delle autorizzazioni per un account di servizio e solo Pods che utilizzano quell'account di servizio hanno accesso a tali autorizzazioni. Questa caratteristica elimina anche la necessità di soluzioni di terze parti, ad esempio kiam o kube2iam.

• Isolamento delle credenziali: A Pod's i contenitori possono recuperare solo le credenziali per il IAM ruolo associato all'account di servizio utilizzato dal contenitore. Un contenitore non ha mai accesso alle credenziali utilizzate da altri contenitori in altri Pods. Quando si utilizzano IAM i ruoli per gli account di servizio, Pod's i container hanno anche le autorizzazioni assegnate al IAMruolo del EKS nodo Amazon, a meno che tu non blocchi Pod accesso ad Amazon EC2 Instance Metadata Service (IMDS). Per ulteriori informazioni, consulta Limitazione dell'accesso al profilo dell'istanza assegnato al nodo worker.

• Verificabilità: la registrazione degli accessi e degli eventi è disponibile AWS CloudTrail per garantire un controllo retrospettivo.

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

1. Crea un IAM OIDC provider per il tuo cluster: questa procedura viene completata una sola volta per ogni cluster.

   Nota

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

   ** server can't find oidc.eks.region.amazonaws.com: NXDOMAIN

   Per completare questo passaggio, è possibile eseguire il comando all'esternoVPC, ad esempio in AWS CloudShell o su un computer connesso a Internet. In alternativa, è possibile creare un resolver condizionale a orizzonte diviso inVPC, ad esempio Route 53 Resolver, per utilizzare un resolver diverso per l'Emittente e non utilizzarlo per esso. OIDC URL VPC DNS Per un esempio di inoltro condizionale in CoreDNS, consulta la richiesta EKS di funzionalità Amazon su GitHub.

2. Assign IAM ruoli per Kubernetes account di servizio: completa questa procedura per ogni set univoco di autorizzazioni che desideri abbia un'applicazione.

3. Configura Pods usare un Kubernetes account di servizio— Completa questa procedura per ciascuno Pod a cui è necessario accedere Servizi AWS.

4. Utilizzare IRSA con AWS SDK— Conferma che il carico di lavoro utilizzi una AWS SDK delle versioni supportate e che utilizzi la catena di credenziali predefinita.

IAM, Kubernetese OpenID Connect (OIDC) informazioni di base

Nel 2014, è AWS Identity and Access Management stato aggiunto il supporto per le identità federate utilizzando OpenID Connect (OIDC). Questa funzionalità consente di autenticare le AWS API chiamate con i provider di identità supportati e di ricevere un messaggio valido OIDC JSON token web (JWT). È possibile passare questo token all' AWS STS AssumeRoleWithWebIdentityAPIoperazione e ricevere credenziali di ruolo IAM temporanee. È possibile utilizzare queste credenziali per interagire con qualsiasi servizio Servizio AWS, tra cui Amazon S3 e DynamoDB.

Ogni JWT token è firmato da una coppia di key pair di firma. Le chiavi vengono fornite dal OIDC provider gestito da Amazon EKS e la chiave privata ruota ogni 7 giorni. Amazon EKS conserva le chiavi pubbliche fino alla loro scadenza. Se connetti OIDC client esterni, tieni presente che devi aggiornare le chiavi di firma prima della scadenza della chiave pubblica. Scopri come effettuare il Recupera le chiavi di firma per convalidare i token OIDC.

Kubernetes utilizza da tempo gli account di servizio come sistema di identità interno. Pods può autenticarsi con Kubernetes APIserver che utilizzava un token montato automaticamente (che non eraOIDC JWT) che solo il Kubernetes APIil server potrebbe convalidare. Questi token legacy dell'account di servizio non hanno scadenza e la rotazione della chiave di firma è un processo difficile. In Kubernetes versione1.12, è stato aggiunto il supporto per una nuova ProjectedServiceAccountToken funzionalità. Questa funzionalità è una OIDC JSON token web che contiene anche l'identità dell'account del servizio e supporta un pubblico configurabile.

Amazon EKS ospita un pubblico OIDC endpoint di scoperta per ogni cluster che contiene le chiavi di firma per ProjectedServiceAccountToken JSON token web in modo che i sistemi esterni, ad esempioIAM, possano convalidare e accettare il OIDC token emessi da Kubernetes.