Aidez à améliorer cette page

Vous souhaitez contribuer à ce guide de l'utilisateur ? Faites défiler cette page vers le bas et sélectionnez Modifier cette page sur GitHub. Vos contributions aideront à améliorer notre guide de l'utilisateur pour tout le monde.

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 AWSKubernetes

Un compte de service Kubernetes fournit une identité pour les processus exécutés dans un Pod. Pour plus d'informations, consultez la rubrique Gestion des comptes de service dans la documentation Kubernetes. Si vous avez Pod besoin d'accéder à AWS des services, vous pouvez associer le compte de service à une AWS Identity and Access Management identité pour accorder cet accès. Pour de plus amples informations, veuillez consulter Rôles IAM pour les comptes de service.

Jetons de compte de service

La fonctionnalité BoundServiceAccountTokenVolume est activée par défaut dans les versions Kubernetes. Cette fonctionnalité améliore la sécurité des jetons de compte de service en permettant aux charges de travail en cours d'exécution Kubernetes de demander des jetons JSON Web 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 période d'expiration. Cela signifie que les clients qui exploitent ces jetons doivent actualiser les jetons en moins d'une heure. Les jetons Kubernetesclient 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 garantir une migration en douceur 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, en plus de la période par défaut d'une heure. Pour les EKS clusters Amazon, la période d'expiration prolongée est de 90 jours. Le Kubernetes API serveur de votre EKS cluster Amazon 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 API serveur reçoit des demandes contenant des jetons datant de plus d'une heure, il annote l'événement du journal API d'audit avecannotations.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 membres de votre EKS cluster Amazon 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 API serveur sont refusées lorsque le délai elapsedtime dépasse 90 jours (7 776 000 secondes). Vous devez mettre à jour le Kubernetes client de vos applications de manière proactive SDK 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 ne disposez pas de suffisamment de temps pour mettre à jour SDK les versions de vos clients avant l'expiration du jeton, vous pouvez résilier le jeton existant Pods et en créer de nouvelles. 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, pour résilier les Pods tout en conservant une haute disponibilité, il est suggéré 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 Kubernetes client SDKs qui récupère 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 Identity and Access Management d'autorisations aux charges de travail sur les clusters Amazon Elastic Kubernetes Service

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

Comparaison entre EKS Pod Identity et IRSA

À un niveau élevé, EKS Pod Identity vous IRSA permet d'accorder des IAM autorisations 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.