Aiutaci a migliorare questa pagina

Vuoi contribuire a questa guida per l'utente? Scorri fino alla fine di questa pagina e seleziona Modifica questa pagina su GitHub. I tuoi contributi contribuiranno a rendere la nostra guida utente migliore per tutti.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Concedi ai carichi di lavoro Kubernetes l'accesso all'utilizzo AWSKubernetes Account di servizio

A Kubernetes l'account di servizio fornisce un'identità per i processi eseguiti in un Pod. Per ulteriori informazioni, vedere Gestione degli account di servizio nel Kubernetes documentazione. Se le ricette di Pod se ha bisogno di accedere ai AWS servizi, è possibile mappare l'account del servizio a un' AWS Identity and Access Management identità per concedere tale accesso. Per ulteriori informazioni, consulta Ruoli IAM per gli account di servizio.

Token dell'account di servizio

La BoundServiceAccountTokenVolumefunzionalità è abilitata per impostazione predefinita in Kubernetes versioni. Questa funzionalità migliora la sicurezza dei token degli account di servizio consentendo l'esecuzione dei carichi di lavoro su Kubernetes per richiedere token JSON web che siano associati a audience, orario e chiave. I token dell'account di servizio scadono entro un'ora, In precedenza Kubernetes Nelle versioni, i token non avevano una scadenza. Di conseguenza, i client che si basano su questi token devono aggiornarli entro un'ora. Quanto segue Kubernetes i token SDKs di aggiornamento automatico del client entro il periodo di tempo richiesto:

Se il carico di lavoro utilizza una versione precedente del client, è necessario aggiornarla. Per consentire una migrazione fluida dei client ai nuovi token degli account di servizio con scadenza temporale, Kubernetes aggiunge un periodo di scadenza esteso al token dell'account di servizio oltre l'ora predefinita. Per EKS i cluster Amazon, il periodo di scadenza esteso è di 90 giorni. I tuoi EKS cluster Amazon Kubernetes APIil server rifiuta le richieste con token che risalgono a più di 90 giorni fa. Ti consigliamo di controllare le tue applicazioni e le relative dipendenze per assicurarti che il client Kubernetes sia uguale o successivo alle versioni SDKs elencate in precedenza.

Quando il API server riceve richieste con token che risalgono a più di un'ora, annota l'evento del registro di controllo con. API annotations.authentication.k8s.io/stale-token Il valore dell'annotazione è simile a quello riportato di seguito:

subject: system:serviceaccount:common:fluent-bit, seconds after warning threshold: 4185802.

Se nel cluster è abilitata la registrazione del piano di controllo (control-plane), le annotazioni di trovano nei registri di controllo. È possibile utilizzare la seguente query CloudWatch Logs Insights per identificare tutti i Pods nel tuo EKS cluster Amazon che utilizzano token obsoleti:

fields @timestamp
| filter @logStream like /kube-apiserver-audit/
| filter @message like /seconds after warning threshold/
| parse @message "subject: *, seconds after warning threshold:*\"" as subject, elapsedtime

si subject riferisce all'account di servizio che Pod usato. elapsedtime indica in secondi il tempo trascorso dalla lettura dell'ultimo token. Le richieste al API server vengono negate quando elapsedtime superano i 90 giorni (7.776.000 secondi). Dovresti aggiornare in modo proattivo le tue applicazioni» Kubernetes client SDK per utilizzare una delle versioni elencate in precedenza che aggiorna automaticamente il token. Se il token dell'account di servizio utilizzato dura da quasi 90 giorni e non hai tempo sufficiente per aggiornare SDK le versioni del client prima della scadenza del token, puoi terminare il token esistente Pods e creane di nuovi. Ciò comporta il ripristino del token dell'account di servizio, che ti offre altri 90 giorni per aggiornare la versione del client. SDKs

Se il file Pod fa parte di una distribuzione, il modo consigliato per terminare Pods pur mantenendo un'elevata disponibilità, è necessario eseguire un rollout con il seguente comando. Sostituisci my-deployment con il nome della tua implementazione.

kubectl rollout restart deployment/my-deployment

Componenti aggiuntivi del cluster

I seguenti componenti aggiuntivi del cluster sono stati aggiornati per utilizzare il Kubernetes client SDKs che recupera automaticamente i token degli account di servizio. Assicurati che le versioni elencate, o versioni successive, siano installate sul tuo cluster.

Concessione AWS Identity and Access Management delle autorizzazioni ai carichi di lavoro sui cluster Amazon Elastic Kubernetes Service

Amazon EKS offre due modi per concedere AWS Identity and Access Management le autorizzazioni ai carichi di lavoro eseguiti nei EKS cluster Amazon: IAMruoli per gli account di servizio e EKS identità Pod.

Confronto tra EKS Pod Identity e IRSA

Ad alto livello, sia EKS Pod Identity che IRSA consentono di concedere IAM autorizzazioni alle applicazioni in esecuzione su cluster Kubernetes. Ma sono fondamentalmente diversi nel modo in cui vengono configurati, nei limiti supportati e nelle funzionalità abilitate. Di seguito, confrontiamo alcuni degli aspetti chiave di entrambe le soluzioni.