Aidez à améliorer cette page

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Autoriser les charges de travail Kubernetes à utiliser les comptes de service Kubernetes AWS

Gestion des comptes de serviceRôles IAM pour les comptes de serviceDécouvrir comment l’identité du pod Amazon EKS accorde aux pods l’accès aux services AWS

Jetons de compte de service

La BoundServiceAccountTokenVolumefonctionnalité est activée par défaut dans les versions de Kubernetes. Cette fonctionnalité améliore la sécurité des jetons de compte de service en permettant aux charges de travail exécutées sur Kubernetes de demander des jetons Web JSON liés à l'audience, à l'heure et à la clé. Les jetons de compte de service ont une expiration d'une heure. Dans les versions antérieures de Kubernetes, les jetons n’avaient pas de date d’expiration. Cela signifie que les clients qui s'appuient sur ces jetons doivent actualiser les jetons en moins d'une heure. Les kits SDK client Kubernetes suivants actualisent automatiquement les jetons dans le délai requis :

Si votre charge de travail utilise une version client antérieure, vous devez la mettre à jour. Afin de permettre une migration fluide des clients vers les nouveaux jetons de compte de service à durée limitée, Kubernetes ajoute une période d’expiration prolongée au jeton de compte de service, au-delà de l’heure par défaut. Pour les clusters Amazon EKS, la période d'expiration prolongée est de 90 jours. Le serveur API Kubernetes de votre cluster Amazon EKS rejette les demandes dont les jetons ont plus de 90 jours. Nous vous recommandons de vérifier vos applications et leurs dépendances pour vous assurer que les SDK des clients Kubernetes sont de versions identiques ou ultérieures aux versions répertoriées ci-dessus.

Lorsque le serveur API reçoit des requêtes avec des jetons de plus d'une heure, il annote l'événement du journal d'audit de l'API avec annotations.authentication.k8s.io/stale-token. La valeur de l'annotation ressemble à l'exemple suivant :

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

Si votre cluster a une journalisation de plan de contrôle activée, les annotations se trouvent dans les journaux d'audit. Vous pouvez utiliser la requête CloudWatch Logs Insights suivante pour identifier tous les pods de votre cluster Amazon EKS qui utilisent des jetons périmés :

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

Le subject fait référence au compte de service utilisé par le pod. Le elapsedtime indique le temps écoulé (en secondes) après la lecture du dernier jeton. Les demandes adressées au serveur d'API sont refusées lorsque le elapsedtime dépasse 90 jours (7 776 000 secondes). Il est recommandé de mettre à jour de manière proactive le kit SDK client Kubernetes de vos applications afin d’utiliser l’une des versions répertoriées précédemment qui actualisent automatiquement le jeton. Si le jeton de compte de service utilisé approche les 90 jours et que vous ne disposez pas de suffisamment de temps pour mettre à jour les versions de votre kit SDK client avant l’expiration du jeton, vous pouvez résilier les pods existants et en créer de nouveaux. Il en résulte une récupération du jeton de compte de service, ce qui vous donne 90 jours supplémentaires pour mettre à jour les kits SDK de votre version client.

Si le pod fait partie d’un déploiement, la suggestion pour résilier les pods tout en conservant une haute disponibilité consiste à effectuer un déploiement à l’aide de la commande suivante. Remplacez my-deployment par le nom de votre déploiement.

kubectl rollout restart deployment/my-deployment

Modules complémentaires de cluster

Les modules complémentaires de cluster suivants ont été mis à jour afin d’utiliser les SDK clients Kubernetes qui récupèrent automatiquement les jetons de compte de service. Nous vous recommandons de vous assurer que les versions répertoriées, ou des versions ultérieures, sont installées sur votre cluster.

Octroi AWS d'autorisations Identity and Access Management aux charges de travail sur les clusters Amazon Elastic Kubernetes Service

Amazon EKS propose deux méthodes pour accorder des autorisations AWS Identity and Access Management aux charges de travail exécutées dans des clusters Amazon EKS : les rôles IAM pour les comptes de service et les identités EKS Pod.

Comparaison de l’identité du pod EKS et de l’IRSA

À un niveau élevé, l’identité du pod EKS et l’IRSA vous permettent tous deux d’accorder des autorisations IAM aux applications exécutées sur des clusters Kubernetes. Mais ils sont fondamentalement différents dans la façon dont vous les configurez, les limites prises en charge et les fonctionnalités activées. Ci-dessous, nous comparons certains des aspects clés des deux solutions.