Configurare l’endpoint del Servizio di token di sicurezza AWS per un account di servizio - Amazon EKS

Contribuisci a migliorare questa pagina

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à.

Per contribuire a questa guida per l'utente, scegli il GitHub link Modifica questa pagina nel riquadro destro di ogni pagina.

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à.

Configurare l’endpoint del Servizio di token di sicurezza AWS per un account di servizio

Se si utilizza un account di servizio Kubernetes con ruoli IAM per gli account di servizio, è possibile configurare il tipo di endpoint del Servizio di token di sicurezza AWS utilizzato dall’account di servizio.

AWS consiglia di utilizzare gli endpoint AWS STS Regionali anziché l’endpoint globale. Ciò riduce la latenza, fornisce una ridondanza integrata e aumenta la validità del token di sessione. Il Servizio di token di sicurezza AWS deve essere attivo nella Regione AWS in cui viene eseguito il pod. Inoltre, l’applicazione deve avere una ridondanza incorporata per una Regione AWS diversa nel caso di un guasto del servizio nella Regione AWS iniziale. Per ulteriori informazioni, consultare Managing AWS STS in an AWS Region nella Guida per l’utente di IAM.

Tutti gli esempi seguenti utilizzano l’account di servizio Kubernetes aws-node utilizzato dal plugin CNI di Amazon VPC. I valori di esempio possono essere sostituiti con gli account di servizio, i pod, i namespace e altre risorse personalizzate.

  1. Selezionare un pod che utilizza un account di servizio per il quale si desidera modificare l’endpoint. Determinare in quale Regione AWS viene eseguito il pod. Sostituire aws-node-6mfgv con il namespace e kube-system con il namespace del pod.

    kubectl describe pod aws-node-6mfgv -n kube-system |grep Node:

    Di seguito viene riportato un output di esempio:

    ip-192-168-79-166.us-west-2/192.168.79.166

    Nell’output precedente, il pod è in esecuzione su un nodo nella Regione AWS us-west-2.

  2. Determinare il tipo di endpoint utilizzato dall’account di servizio del pod.

    kubectl describe pod aws-node-6mfgv -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS

    Di seguito viene riportato un output di esempio:

    AWS_STS_REGIONAL_ENDPOINTS: regional

    Se l'endpoint attuale è globale, l'output restituisce global. Se non viene restituito alcun output, il tipo di endpoint predefinito è in uso e non è stato sovrascritto.

  3. Se le versioni del cluster e della piattaforma corrispondono o sono successive a quelle elencate nella tabella, puoi modificare il tipo di endpoint utilizzato dall'account del servizio dal tipo predefinito con un tipo diverso tramite uno dei comandi seguenti. Sostituisci aws-node con il nome dell'account del servizio e kube-system con lo spazio dei nomi dell'account del servizio.

    • Se il tipo di endpoint predefinito o attuale è globale e vuoi modificarlo in regionale:

      kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=true

      Se si utilizzano i ruoli IAM per gli account di servizio per generare URL S3 prefirmati nell’applicazione in esecuzione nei container dei pod, il formato dell’URL per gli endpoint Regionali è simile al seguente esempio:

      https://bucket.s3.us-west-2.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...

    • Se il tipo di endpoint predefinito o attuale è regionale e vuoi modificarlo in globale:

      kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=false

      Se l’applicazione sta effettuando esplicitamente richieste agli endpoint AWS STS globali e non si sostituisce il comportamento predefinito di utilizzo degli endpoint Regionali in cluster Amazon EKS, le richieste avranno esito negativo e restituiranno un codice di errore. Per ulteriori informazioni, consulta I container dei pod riceveranno il seguente errore: An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: Credential should be scoped to a valid region.

      Se si utilizzano i ruoli IAM per gli account di servizio per generare URL S3 prefirmati nell’applicazione in esecuzione nei container dei pod, il formato dell’URL per gli endpoint globali è simile al seguente esempio:

      https://bucket.s3.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...

    Se si dispone di un sistema di automazione che prevede un determinato formato per l’URL prefirmato o se l’applicazione o le dipendenze a valle che utilizzano gli URL prefirmati hanno aspettative per la Regione AWS di destinazione, apportare le modifiche necessarie per utilizzare l’endpoint AWS STS appropriato.

  4. Eliminare e ricreare i pod esistenti associati all’account di servizio per applicare le variabili di ambiente delle credenziali. Il web hook di modifica non le applica ai pod già in esecuzione. È possibile sostituire Pods, kube-system e -l k8s-app=aws-node con le informazioni dei pod per cui viene impostata l’annotazione.

    kubectl delete Pods -n kube-system -l k8s-app=aws-node

  5. Verificare che tutti i pod siano stati riavviati.

    kubectl get Pods -n kube-system -l k8s-app=aws-node

  6. Visualizzare le variabili di ambiente per uno dei pod. Verifica che il valore AWS_STS_REGIONAL_ENDPOINTS sia quello che hai impostato in una fase precedente.

    kubectl describe pod aws-node-kzbtr -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS

    Di seguito viene riportato un output di esempio:

    AWS_STS_REGIONAL_ENDPOINTS=regional