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écouvrez comment EKS Pod Identity permet aux pods d'accéder aux AWS services

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 d'expiration. Cela signifie que les clients qui exploitent ces jetons doivent actualiser les jetons en moins d'une heure. Les clients Kubernetes suivants SDKs actualisent automatiquement les jetons dans les délais requis :

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

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). Vous devez mettre à jour le SDK client Kubernetes de vos applications de manière proactive afin d'utiliser l'une des versions répertoriées précédemment qui actualise automatiquement le jeton. Si le jeton de compte de service utilisé dure près de 90 jours et que vous n'avez pas suffisamment de temps pour mettre à jour les versions du SDK client avant l'expiration du jeton, vous pouvez résilier les pods existants et en créer de nouveaux. Cela entraîne la récupération du jeton du compte de service, ce qui vous donne 90 jours supplémentaires pour mettre à jour la version de votre client. SDKs

Si le Pod fait partie d'un déploiement, la méthode suggérée pour mettre fin aux Pods tout en conservant une haute disponibilité est d'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 pour utiliser le client Kubernetes SDKs qui récupère automatiquement les jetons des comptes 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 principaux aspects des deux solutions.