**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. # Accorder aux charges de travail Kubernetes l’accès à AWS à l’aide des comptes de service Kubernetes Accès des charges de travail à AWS[Gestion des comptes de service](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin)[Rôles IAM pour les comptes de service](iam-roles-for-service-accounts.md)[Découvrir comment l’identité du pod Amazon EKS accorde aux pods l’accès aux services AWS](pod-identities.md) ## Jetons de compte de service La fonctionnalité [BoundServiceAccountTokenVolume](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume) 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 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](https://kubernetes.io/docs/reference/using-api/client-libraries/) suivants actualisent automatiquement les jetons dans le délai requis : + Go version `0.15.7` et ultérieure + Python version `12.0.0` et ultérieure + Java version `9.0.0` et ultérieure + JavaScript version `0.10.3` et ultérieure + Branche `master` Ruby + Haskell version `0.3.0.0` + Version C\$1 `7.0.5` et ultérieure 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](control-plane-logs.md) activée, les annotations se trouvent dans les journaux d'audit. Vous pouvez utiliser la requête [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) 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. + Plug-in CNI Amazon VPC pour Kubernetes et plug-ins d’aide aux métriques version `1.8.0` et ultérieure. Pour vérifier votre version actuelle ou la mettre à jour, consultez [Attribuer IPs à des pods avec l'Amazon VPC CNI](managing-vpc-cni.md) et [cni-metrics-helper](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/cmd/cni-metrics-helper/README.md). + CoreDNS version `1.8.4` et ultérieure. Pour vérifier votre version actuelle ou la mettre à jour, consultez [Gérer CoreDNS pour DNS dans les clusters Amazon EKS](managing-coredns.md). + AWS Load Balancer Controller version `2.0.0` et ultérieure. Pour vérifier votre version actuelle ou la mettre à jour, consultez [Acheminez le trafic Internet avec le AWS Load Balancer Controller](aws-load-balancer-controller.md). + Une version actuelle de `kube-proxy`. Pour vérifier votre version actuelle ou la mettre à jour, consultez [Gérer `kube-proxy` dans les Clusters Amazon EKS](managing-kube-proxy.md). + AWS pour Fluent Bit version `2.25.0` ou ultérieure. Pour mettre à jour votre version actuelle, consultez [Versions](https://github.com/aws/aws-for-fluent-bit/releases) sur GitHub. + Version d'image Fluentd [1.14.6-1.2](https://hub.docker.com/r/fluent/fluentd/tags?page=1&name=v1.14.6-1.2) ou version ultérieure et plug-in de filtre Fluentd pour les métadonnées de Kubernetes version [2.11.1](https://rubygems.org/gems/fluent-plugin-kubernetes_metadata_filter/versions/2.11.1) ou ultérieure. ## Octroi d’autorisations de gestion des identités et des accès AWS aux charges de travail sur les clusters Amazon Elastic Kubernetes Service Amazon EKS propose deux méthodes pour octroyer des autorisations de gestion des identités et des accès AWS aux charges de travail qui s’exécutent dans les clusters Amazon EKS : *Rôles IAM pour les comptes de service* et *Identités du pod EKS*. **Rôles IAM pour les comptes de service** Les *rôles IAM des comptes de service (IRSA)* configurent les applications Kubernetes s’exécutant sur AWS avec des autorisations IAM détaillées pour accéder à diverses autres ressources AWS, telles que les compartiments Amazon S3, les tables Amazon DynamoDB, etc. Vous pouvez exécuter plusieurs applications ensemble dans le même cluster Amazon EKS, et vous assurer que chaque application ne dispose que de l’ensemble minimum d’autorisations dont elle a besoin. IRSA a été créé pour prendre en charge diverses options de déploiement Kubernetes prises en charge par AWS, telles qu’Amazon EKS, Amazon EKS Anywhere, Red Hat OpenShift Service sur AWS et les clusters Kubernetes autogérés sur les instances Amazon EC2. Ainsi, IRSA a été créé en utilisant un service AWS fondamental comme IAM, et n’a pas pris de dépendance directe sur le service Amazon EKS et l’API EKS. Pour de plus amples informations, consultez [Rôles IAM pour les comptes de service](iam-roles-for-service-accounts.md). **Identités des pods EKS** L’identité du pod EKS offre aux administrateurs de cluster un flux simplifié pour l’authentification des applications afin d’accéder à diverses autres ressources AWS telles que les compartiments Amazon S3, les tables Amazon DynamoDB, etc. L’identité du pod EKS est réservée uniquement à EKS et, par conséquent, elle simplifie la manière dont les administrateurs de cluster peuvent configurer les applications Kubernetes pour obtenir des autorisations IAM. Ces autorisations peuvent désormais être facilement configurées en quelques étapes directement via AWS Management Console, l’API EKS et l’interface AWS CLI, et aucune action n’est requise à l’intérieur du cluster dans les objets Kubernetes. Les administrateurs de clusters n’ont pas besoin de basculer entre les services EKS et IAM, ni d’utiliser des opérations IAM privilégiées pour configurer les autorisations requises par vos applications. Les rôles IAM peuvent désormais être utilisés dans plusieurs clusters sans qu’il soit nécessaire de mettre à jour la politique d’approbation des rôles lors de la création de nouveaux clusters. Les informations d’identification IAM fournies par l’identité du pod EKS comprennent des balises de session de rôle, avec des attributs tels que le nom du cluster, l’espace de noms, le nom du compte de service. Les balises de session de rôle permettent aux administrateurs de créer un rôle unique qui peut fonctionner sur plusieurs comptes de service en autorisant l’accès aux ressources AWS sur la base des balises correspondantes. Pour de plus amples informations, consultez [Découvrir comment l’identité du pod Amazon EKS accorde aux pods l’accès aux services AWS](pod-identities.md). ### 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. **Note** AWS recommande d’utiliser les identités du pod EKS pour accorder l’accès aux ressources AWS à vos pods dans la mesure du possible. Pour de plus amples informations, consultez [Découvrir comment l’identité du pod Amazon EKS accorde aux pods l’accès aux services AWS](pod-identities.md). | Attribut | Identité du pod EKS | IRSA | | --- | --- | --- | | Extensibilité des rôles | Vous devez configurer chaque rôle une fois pour établir la confiance avec le nouveau principal de service Amazon EKS `pods.eks.amazonaws.com`. Après cette étape unique, vous n’avez pas besoin de mettre à jour la politique d’approbation du rôle à chaque fois qu’il est utilisé dans un nouveau cluster. | Vous devez mettre à jour la politique d’approbation du rôle IAM avec le nouveau point de terminaison du fournisseur OIDC du cluster EKS chaque fois que vous voulez utiliser le rôle dans un nouveau cluster. | | Capacité de mise à l’échelle des clusters | L’identité du pod EKS n’exige pas des utilisateurs qu’ils configurent le fournisseur IAM OIDC, cette limite ne s’applique donc pas. | Chaque cluster EKS est associé à une URL d’émetteur OpenID Connect (OIDC). Pour utiliser IRSA, un fournisseur OpenID Connect unique doit être créé pour chaque cluster EKS dans IAM. IAM a une limite globale par défaut de 100 fournisseurs OIDC pour chaque compte AWS. Si vous prévoyez d’avoir plus de 100 clusters EKS pour chaque compte AWS avec IRSA, vous atteindrez la limite du fournisseur IAM OIDC. | | Capacité de mise à l’échelle des rôles | L’identité du pod EKS n’exige pas des utilisateurs qu’ils définissent une relation d’approbation entre le rôle IAM et le compte de service dans la politique d’approbation, cette limite ne s’applique donc pas. | Dans IRSA, vous définissez la relation d’approbation entre un rôle IAM et un compte de service dans la politique d’approbation du rôle. Par défaut, la longueur de la politique d’approbation est `2048`. Cela signifie que vous pouvez généralement définir 4 relations d’approbation dans une seule politique d’approbation. Bien qu’il soit possible d’augmenter la limite de longueur de la politique d’approbation, vous êtes généralement limité à un maximum de 8 relations d’approbation au sein d’une même politique d’approbation. | | Utilisation du quota d’API STS | L’identité du pod EKS simplifie la fourniture d’informations d’identification AWS à vos pods et ne nécessite pas que votre code effectue des appels directement avec le service de jetons de sécurité AWS (STS). Le service EKS gère l’assomption de rôle et fournit des informations d’identification aux applications écrites à l’aide du kit SDK AWS dans vos pods sans que ceux-ci communiquent avec AWS STS ou utilisent le quota d’API STS. | Dans IRSA, les applications écrites à l’aide du kit SDK AWS dans vos pods utilisent des jetons pour appeler l’API `AssumeRoleWithWebIdentity` sur le service de jetons de sécurité AWS (STS). En fonction de la logique de votre code sur le kit SDK AWS, il est possible que votre code effectue des appels inutiles vers AWS STS et reçoive des erreurs de limitation. | | Réutilisation des rôles | Les informations d’identification temporaires AWS STS fournies par l’identité du pod Amazon EKS comprennent des balises de session de rôle, telles que le nom du cluster, l’espace de noms et le nom du compte de service. Les balises de session de rôle permettent aux administrateurs de créer un rôle IAM unique qui peut être utilisé avec plusieurs comptes de service, avec différentes autorisations effectives, en autorisant l’accès aux ressources AWS en fonction des balises qui leur sont attachées. C’est ce qu’on appelle le contrôle d’accès par attributs (ABAC). Pour de plus amples informations, consultez [Accordez aux Pods l'accès aux AWS ressources en fonction des balises](pod-id-abac.md). | Les balises de session AWS STS ne sont pas prises en charge. Vous pouvez réutiliser un rôle entre les clusters, mais chaque pod reçoit toutes les autorisations du rôle. | | Environnements pris en charge | L’identité du pod EKS est uniquement disponible sur Amazon EKS. | IRSA peut être utilisé avec Amazon EKS, Amazon EKS Anywhere, Red Hat OpenShift Service sur AWS et les clusters Kubernetes autogérés sur les instances Amazon EC2. | | Versions EKS prises en charge | Toutes les versions de clusters EKS prises en charge. Pour les versions de plateforme spécifiques, consultez [Versions du cluster de l’identité du pod EKS](pod-identities.md#pod-id-cluster-versions). | Toutes les versions de clusters EKS prises en charge. | # Rôles IAM pour les comptes de service Informations d’identification auprès de l’IRSA **Astuce** [Inscrivez-vous](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) aux prochains ateliers Amazon EKS. Les applications situées dans les conteneurs d'un pod peuvent utiliser un AWS SDK ou la AWS CLI pour envoyer des demandes d'API aux AWS services à l'aide des AWS autorisations Identity and Access Management (IAM). Les applications doivent signer leurs demandes AWS d'API avec des AWS informations d'identification. **Les rôles IAM pour les comptes de service (IRSA)** permettent de gérer les informations d'identification de vos applications, de la même manière que les profils d' EC2 instance Amazon fournissent des informations d'identification aux instances Amazon EC2 . Au lieu de créer et de distribuer vos AWS informations d'identification aux conteneurs ou d'utiliser le rôle de l' EC2 instance Amazon, vous associez un rôle IAM à un compte de service Kubernetes et configurez vos Pods pour utiliser le compte de service. Vous ne pouvez pas utiliser de rôles IAM pour des comptes de service dotés de [clusters locaux pour Amazon EKS on AWS Outposts](eks-outposts-local-cluster-overview.md). Les rôles IAM pour les comptes de service offrent les bénéfices suivants : + **Moindre privilège** : vous pouvez définir les autorisations IAM sur un compte de service et seuls les pods qui utilisent ce compte de service ont accès à ces autorisations. Cette fonctionnalité élimine également le besoin de solutions tierces telles que `kiam` ou `kube2iam`. + **Isolation des informations d'identification** : lorsque l'accès à l'[Amazon EC2 Instance Metadata Service (IMDS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) est restreint, les conteneurs d'un pod peuvent uniquement récupérer les informations d'identification pour le rôle IAM associé au compte de service utilisé par le conteneur. Un conteneur n’a jamais accès aux informations d’identification qui sont utilisées par d’autres conteneurs dans d’autres pods. Si IMDS n’est pas restreint, les conteneurs du Pod ont également accès au [rôle IAM du nœud Amazon EKS](create-node-role.md) et les conteneurs peuvent être en mesure d’accéder aux informations d’identification des rôles IAM d’autres Pods sur le même nœud. Pour plus d'informations, consultez [Restreindre l'accès au profil d'instance affecté au composant master](https://docs.aws.amazon.com/eks/latest/best-practices/identity-and-access-management.html#_identities_and_credentials_for_eks_pods_recommendations). **Note** Les pods configurés avec `hostNetwork: true` auront toujours un accès IMDS, mais la CLI AWS SDKs and utilisera les informations d'identification IRSA lorsqu'elle est activée. + **Auditabilité — La** journalisation des accès et des événements est disponible AWS CloudTrail pour garantir un audit rétrospectif. **Important** Les conteneurs ne constituent pas une limite de sécurité, et l’utilisation de rôles IAM pour les comptes de service ne change rien à cela. Les pods attribués au même nœud partageront un noyau et éventuellement d’autres ressources en fonction de la configuration de votre pod. Bien que les pods s’exécutant sur des nœuds distincts soient isolés au niveau de la couche de calcul, certaines applications de nœuds disposent d’autorisations supplémentaires dans l’API Kubernetes qui dépassent le champ d’application d’une instance individuelle. Quelques exemples : `kubelet`, `kube-proxy`, les pilotes de stockage CSI ou vos propres applications Kubernetes. Activez les rôles IAM pour les comptes de service en suivant les procédures suivantes : 1. [Créez un fournisseur IAM OIDC pour votre cluster](enable-iam-roles-for-service-accounts.md) : vous ne devez effectuer cette procédure qu’une seule fois pour chaque cluster. **Note** Si vous avez activé le point de terminaison d’un VPC EKS, le point de terminaison du service OIDC EKS n’était pas accessible depuis l’intérieur de ce VPC. Par conséquent, les opérations telles que la création d'un fournisseur OIDC avec `eksctl` dans le VPC n'aboutiront pas et entraîneront une expiration lors de la tentative de demande de `https://oidc.eks.region.amazonaws.com`. Voici un exemple de message d'erreur : ``` server cant find oidc.eks.region.amazonaws.com: NXDOMAIN ``` Pour terminer cette étape, vous pouvez exécuter la commande en dehors du VPC, par exemple dans AWS CloudShell ou sur un ordinateur connecté à Internet. Vous pouvez également créer un résolveur conditionnel à horizon divisé dans le VPC, tel que Route 53 Resolver, afin d’utiliser un résolveur différent pour l’URL de l’émetteur OIDC et de ne pas utiliser le DNS VPC pour celle-ci. Pour un exemple de transfert conditionnel dans CoreDNS, consultez la demande de fonctionnalité [Amazon EKS sur](https://github.com/aws/containers-roadmap/issues/2038). GitHub 1. [Attribuer des rôles IAM aux comptes de service Kubernetes](associate-service-account-role.md) : suivez cette procédure pour chaque ensemble unique d’autorisations que vous souhaitez attribuer à une application. 1. [Configurer les pods pour utiliser un compte de service Kubernetes](pod-configuration.md) : effectuez cette procédure pour chaque pod devant accéder aux services. AWS 1. [Utiliser IRSA avec le AWS SDK](iam-roles-for-service-accounts-minimum-sdk.md) : vérifiez que la charge de travail utilise un AWS SDK d'une version prise en charge et qu'elle utilise la chaîne d'identification par défaut. ## Informations générales sur IAM, Kubernetes et OpenID Connect (OIDC) En 2014, AWS Identity and Access Management a ajouté la prise en charge des identités fédérées à l'aide d'OpenID Connect (OIDC). Cette fonctionnalité vous permet d'authentifier les appels d' AWS API auprès des fournisseurs d'identité pris en charge et de recevoir un jeton Web OIDC JSON (JWT) valide. Vous pouvez transmettre ce jeton à l'opération de l'`AssumeRoleWithWebIdentity`API AWS STS et recevoir des informations d'identification de rôle temporaires IAM. Vous pouvez utiliser ces informations d'identification pour interagir avec n'importe quel AWS service, y compris Amazon S3 et DynamoDB. Chaque jeton JWT est signé par une paire de clés de signature. Les clés sont servies sur le fournisseur OIDC géré par Amazon EKS et la clé privée change tous les 7 jours. Amazon EKS conserve les clés publiques jusqu'à leur expiration. Si vous connectez des clients OIDC externes, sachez que vous devez actualiser les clés de signature avant l’expiration de la clé publique. Apprenez à [récupérer les clés de signature pour valider les jetons OIDC](irsa-fetch-keys.md). Kubernetes utilise depuis longtemps les comptes de service comme son propre système d'identité interne. Les pods peuvent s'authentifier auprès du serveur d'API Kubernetes à l'aide d'un jeton monté automatiquement (qui était un JWT non OIDC) que seul le serveur d'API Kubernetes a pu valider. Ces jetons de compte de service hérités n’expirent pas et la rotation de la clé de signature est un processus difficile. Dans la version Kubernetes `1.12`, une nouvelle fonctionnalité `ProjectedServiceAccountToken` a été ajoutée. Cette fonctionnalité est un jeton Web JSON OIDC qui contient également l’identité du compte de service et prend en charge une audience configurable. Amazon EKS héberge un point de terminaison de découverte OIDC public pour chaque cluster qui contient les clés de signature des jetons Web JSON `ProjectedServiceAccountToken` afin que les systèmes externes, tels que IAM, puissent valider et accepter les jetons OIDC émis par Kubernetes. # Créer un fournisseur d'identité OIDC IAM pour votre cluster Fournisseur IAM OIDC Votre cluster a une URL de diffuseur [OpenID Connect](https://openid.net/connect/) (OIDC) qui lui est associée. Pour utiliser les rôles AWS Identity and Access Management (IAM) pour les comptes de service, un fournisseur IAM OIDC doit exister pour l'URL de l'émetteur OIDC de votre cluster. ## Conditions préalables + Un cluster Amazon EKS existant. Pour en déployer un, consultez [Mise en route avec Amazon EKS](getting-started.md). + Version `2.12.3` ou version ultérieure `1.27.160` ou version ultérieure de l'interface de ligne de AWS commande (AWS CLI) installée et configurée sur votre appareil ou AWS CloudShell. Pour vérifier votre version actuelle, utilisez `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Les gestionnaires de packages tels que `yum` Homebrew pour macOS ont souvent plusieurs versions de retard sur la dernière version de la AWS CLI. `apt-get` Pour installer la dernière version, consultez la section [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) et [configuration rapide avec aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) dans le *Guide de l'utilisateur de l'interface de ligne de AWS commande*. La version de la AWS CLI installée AWS CloudShell peut également avoir plusieurs versions de retard par rapport à la dernière version. Pour le mettre à jour, consultez la section [Installation de la AWS CLI dans votre répertoire](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) de base dans le *guide de AWS CloudShell l'utilisateur*. + L'outil de ligne de commande `kubectl` est installé sur votre appareil ou AWS CloudShell. La version peut correspondre à celle utilisée par votre cluster Kubernetes, ou différer d’au plus une version mineure, qu’elle soit antérieure ou plus récente. Par exemple, si la version de votre cluster est `1.29`, vous pouvez utiliser la version `kubectl` `1.28`, `1.29` ou `1.30`. Pour installer ou mettre à niveau `kubectl`, veuillez consulter [Configuration de `kubectl` et `eksctl`](install-kubectl.md). + Un fichier existant `kubectl` `config` qui contient la configuration de votre cluster. Pour créer un fichier `kubectl` `config`, consultez [Connexion de kubectl à un cluster EKS en créant un fichier kubeconfig](create-kubeconfig.md). Vous pouvez créer un fournisseur IAM OIDC pour votre cluster en utilisant `eksctl` ou la AWS Management Console. ## Créer un fournisseur OIDC (eksctl) 1. Version `0.215.0` ou ultérieure de l'outil de ligne de commande `eksctl` installée sur votre appareil ou AWS CloudShell. Pour installer ou mettre à jour `eksctl`, veuillez consulter [Installation](https://eksctl.io/installation) dans la documentation de `eksctl`. 1. Déterminez l’identifiant de l’émetteur OIDC pour votre cluster. Récupérez l’ID émetteur OIDC de votre cluster et stockez-le dans une variable. Remplacez `` par votre propre valeur. ``` cluster_name= oidc_id=$(aws eks describe-cluster --name $cluster_name --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5) echo $oidc_id ``` 1. Déterminez si un fournisseur IAM OIDC avec l’ID d’émetteur de votre cluster figure déjà dans votre compte. ``` aws iam list-open-id-connect-providers | grep $oidc_id | cut -d "/" -f4 ``` Si la sortie est renvoyée, cela signifie que vous disposez déjà d’un fournisseur IAM OIDC pour votre cluster. Vous pouvez donc ignorer l’étape suivante. Si aucune sortie n'est renvoyée, vous devez créer un fournisseur OIDC IAM pour votre cluster. 1. Créez votre fournisseur d'identité OIDC IAM pour votre cluster avec la commande suivante. ``` eksctl utils associate-iam-oidc-provider --cluster $cluster_name --approve ``` **Note** Si vous avez activé le point de terminaison d’un VPC EKS, le point de terminaison du service OIDC EKS n’était pas accessible depuis l’intérieur de ce VPC. Par conséquent, vos opérations telles que la création d’un fournisseur OIDC avec `eksctl` dans le VPC ne fonctionneront pas et entraîneront un délai d’expiration. Voici un exemple de message d'erreur : ``` ** server cant find oidc.eks..amazonaws.com: NXDOMAIN ``` Pour terminer cette étape, vous pouvez exécuter la commande en dehors du VPC, par exemple dans AWS CloudShell ou sur un ordinateur connecté à Internet. Vous pouvez également créer un résolveur conditionnel à horizon divisé dans le VPC, tel que Route 53 Resolver, afin d’utiliser un résolveur différent pour l’URL de l’émetteur OIDC et de ne pas utiliser le DNS VPC pour celle-ci. Pour un exemple de transfert conditionnel dans CoreDNS, consultez la demande de fonctionnalité [Amazon EKS sur](https://github.com/aws/containers-roadmap/issues/2038). GitHub ## Créer un fournisseur OIDC (AWS console) 1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Dans le volet de gauche, sélectionnez **Clusters**, puis sélectionnez le nom de votre cluster sur la page **Clusters**. 1. Dans la section **Détails** de l'onglet **Présentation**, notez la valeur de l'**URL du fournisseur d'OpenID Connect**. 1. Ouvrez la console IAM à https://console.aws.amazon.com/iam/ l'adresse. 1. Dans le panneau de navigation, sélectionnez **Identity Providers** (Fournisseurs d'identité) sous **Access management** (Gestion des accès). Si un **fournisseur** est répertorié et correspond à l'URL de votre cluster, alors vous avez déjà un fournisseur pour votre cluster. Si aucun fournisseur ne correspond à l’URL de votre cluster, vous devez en créer un. 1. Pour créer un fournisseur, cliquez sur **Ajouter un fournisseur**. 1. Pour le **type de fournisseur**, sélectionnez **OpenID Connect**. 1. Pour **l’URL du fournisseur**, saisissez l’URL du fournisseur OIDC pour votre cluster. 1. Pour **Audience**, saisissez `sts.amazonaws.com`. 1. (Facultatif) Ajoutez des balises, par exemple une balise permettant d’identifier le cluster associé à ce fournisseur. 1. Choisissez **Ajouter un fournisseur**. Étape suivante : [Attribution de rôles IAM aux comptes de service Kubernetes](associate-service-account-role.md) # Attribution de rôles IAM aux comptes de service Kubernetes Attribution d’un rôle IAM Cette rubrique explique comment configurer un compte de service Kubernetes pour qu'il assume un rôle AWS Identity and Access Management (IAM). Tous les pods configurés pour utiliser le compte de service peuvent ensuite accéder à tout AWS service auquel le rôle est autorisé à accéder. ## Conditions préalables + Un cluster existant. Si vous n’en avez pas, vous pouvez en créer un en suivant l’un des guides [Mise en route avec Amazon EKS](getting-started.md). + Un fournisseur IAM OpenID Connect (OIDC) existant pour votre cluster. Pour déterminer si vous en avez déjà un ou comment en créer un, consultez [Créer un fournisseur d'identité OIDC IAM pour votre cluster](enable-iam-roles-for-service-accounts.md). + Version `2.12.3` ou version ultérieure `1.27.160` ou version ultérieure de l'interface de ligne de AWS commande (AWS CLI) installée et configurée sur votre appareil ou AWS CloudShell. Pour vérifier votre version actuelle, utilisez `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Les gestionnaires de packages tels que `yum` Homebrew pour macOS ont souvent plusieurs versions de retard sur la dernière version de la AWS CLI. `apt-get` Pour installer la dernière version, consultez la section [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) et [configuration rapide avec aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) dans le *Guide de l'utilisateur de l'interface de ligne de AWS commande*. La version de la AWS CLI installée AWS CloudShell peut également avoir plusieurs versions de retard par rapport à la dernière version. Pour le mettre à jour, consultez la section [Installation de la AWS CLI dans votre répertoire](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) de base dans le *guide de AWS CloudShell l'utilisateur*. + L'outil de ligne de commande `kubectl` est installé sur votre appareil ou AWS CloudShell. La version peut correspondre à celle utilisée par votre cluster Kubernetes, ou différer d’au plus une version mineure, qu’elle soit antérieure ou plus récente. Par exemple, si la version de votre cluster est `1.29`, vous pouvez utiliser la version `kubectl` `1.28`, `1.29` ou `1.30`. Pour installer ou mettre à niveau `kubectl`, veuillez consulter [Configuration de `kubectl` et `eksctl`](install-kubectl.md). + Un fichier existant `kubectl` `config` qui contient la configuration de votre cluster. Pour créer un fichier `kubectl` `config`, consultez [Connexion de kubectl à un cluster EKS en créant un fichier kubeconfig](create-kubeconfig.md). ## Étape 1 : créer une politique IAM Si vous souhaitez associer une politique IAM existante à votre rôle IAM, passez à l'étape suivante. 1. Créez une politique IAM. Vous pouvez créer votre propre politique ou copier une politique AWS gérée qui accorde déjà certaines des autorisations dont vous avez besoin et la personnaliser en fonction de vos besoins spécifiques. Pour plus d’informations, consultez [Création de politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le *Guide de l’utilisateur IAM*. 1. Créez un fichier qui inclut les autorisations pour les AWS services auxquels vous souhaitez que vos pods accèdent. Pour obtenir la liste de toutes les actions pour tous les AWS services, consultez la [référence d'autorisation des services](https://docs.aws.amazon.com/service-authorization/latest/reference/). Vous pouvez exécuter la commande suivante pour créer un exemple de fichier de politique autorisant l'accès en lecture seule à un compartiment Amazon S3. Vous pouvez, si vous le souhaitez, stocker des informations de configuration ou un script d’amorçage dans ce compartiment et les conteneurs de votre pod pourront lire le fichier dans le compartiment et le charger dans votre application. Si vous souhaitez créer cet exemple de politique, copiez le contenu suivant sur votre appareil. *my-pod-secrets-bucket*Remplacez-le par le nom de votre compartiment et exécutez la commande. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::my-pod-secrets-bucket" } ] } ``` 1. Créez la politique IAM. ``` aws iam create-policy --policy-name my-policy --policy-document file://my-policy.json ``` ## Étape 2 : créer et associer un rôle IAM Créez un rôle IAM, puis associez-le à un compte de service Kubernetes. Vous pouvez utiliser l'une ou l'autre `eksctl` option ou la AWS CLI. ### Création et association du rôle (eksctl) Cette commande `eksctl` crée un compte de service Kubernetes dans l’espace de noms spécifié, crée un rôle IAM (s’il n’existe pas) portant le nom indiqué, attache une politique IAM existante au rôle, puis annote le compte de service avec l’ARN du rôle IAM. Veillez à remplacer les valeurs d’exemple de cette commande par vos propres valeurs. Pour installer ou mettre à jour `eksctl`, veuillez consulter [Installation](https://eksctl.io/installation) dans la documentation de `eksctl`. ``` eksctl create iamserviceaccount --name my-service-account --namespace default --cluster my-cluster --role-name my-role \ --attach-policy-arn arn:aws: iam::111122223333:policy/my-policy --approve ``` **Important** Si le rôle ou le compte de service existe déjà, la commande précédente peut échouer. `eksctl` propose différentes options que vous pouvez fournir dans ces situations. Pour de plus amples informations, exécutez `eksctl create iamserviceaccount --help`. ### Créer et associer un rôle (AWS CLI) Si vous avez déjà un compte de service Kubernetes devant assumer un rôle IAM, vous pouvez ignorer cette étape. 1. Créez un compte de service Kubernetes. Copiez les contenus suivants sur votre appareil. *my-service-account*Remplacez-le par le nom de votre choix et *default* par un autre espace de noms, si nécessaire. Si vous modifiez*default*, l'espace de noms doit déjà exister. ``` cat >my-service-account.yaml < Mountable secrets: my-service-account-token-qqjfl Tokens: my-service-account-token-qqjfl [...] ``` ## Étapes suivantes + [Configurer les pods pour utiliser un compte de service Kubernetes](pod-configuration.md) # Configurer les pods pour utiliser un compte de service Kubernetes Attribuer à un pod Si un Pod doit accéder à AWS des services, vous devez le configurer pour utiliser un compte de service Kubernetes. Le compte de service doit être associé à un rôle AWS Identity and Access Management (IAM) autorisé à accéder aux services. AWS + Un cluster existant. Si vous n’en avez pas, vous pouvez en créer un à l’aide de l’un des guides disponibles dans [Mise en route avec Amazon EKS](getting-started.md). + Un fournisseur IAM OpenID Connect (OIDC) existant pour votre cluster. Pour déterminer si vous en avez déjà un ou comment en créer un, consultez [Créer un fournisseur d'identité OIDC IAM pour votre cluster](enable-iam-roles-for-service-accounts.md). + Un compte de service Kubernetes existant associé à un rôle IAM. Le compte de service doit être annoté avec l'Amazon Resource Name (ARN) du rôle IAM. Le rôle doit être associé à une politique IAM contenant les autorisations dont vous souhaitez que vos pods disposent pour utiliser les AWS services. Pour plus d'informations sur la façon de créer et de configurer le compte de service et le rôle, consultez [Attribution de rôles IAM aux comptes de service Kubernetes](associate-service-account-role.md). + Version `2.12.3` ou version ultérieure `1.27.160` ou version ultérieure de l'interface de ligne de AWS commande (AWS CLI) installée et configurée sur votre appareil ou AWS CloudShell. Pour vérifier votre version actuelle, utilisez `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Les gestionnaires de packages tels que `yum` Homebrew pour macOS ont souvent plusieurs versions de retard sur la dernière version de la AWS CLI. `apt-get` Pour installer la dernière version, consultez la section [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) et [configuration rapide avec aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) dans le *Guide de l'utilisateur de l'interface de ligne de AWS commande*. La version de la AWS CLI installée AWS CloudShell peut également avoir plusieurs versions de retard par rapport à la dernière version. Pour le mettre à jour, consultez la section [Installation de la AWS CLI dans votre répertoire](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) de base dans le *guide de AWS CloudShell l'utilisateur*. + L'outil de ligne de commande `kubectl` est installé sur votre appareil ou AWS CloudShell. La version peut correspondre à celle utilisée par votre cluster Kubernetes, ou différer d’au plus une version mineure, qu’elle soit antérieure ou plus récente. Par exemple, si la version de votre cluster est `1.29`, vous pouvez utiliser la version `kubectl` `1.28`, `1.29` ou `1.30`. Pour installer ou mettre à niveau `kubectl`, veuillez consulter [Configuration de `kubectl` et `eksctl`](install-kubectl.md). + Un fichier existant `kubectl` `config` qui contient la configuration de votre cluster. Pour créer un fichier `kubectl` `config`, consultez [Connexion de kubectl à un cluster EKS en créant un fichier kubeconfig](create-kubeconfig.md). 1. Utilisez la commande suivante pour créer un manifeste de déploiement que vous pouvez déployer sur un pod afin de confirmer la configuration. Remplacez les exemples de valeurs par vos propres valeurs. ``` cat >my-deployment.yaml <my-service-account.yaml <my-deployment.yaml <