**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.
# Présentation du fonctionnement du contrôle d’accès dans Amazon EKS
Découvrez comment gérer l’accès à votre cluster Amazon EKS. L'utilisation d'Amazon EKS nécessite de connaître la manière dont Kubernetes et AWS Identity and Access Management (AWS IAM) gèrent le contrôle d'accès.
**Contenu de cette section :**
**[Accorder aux utilisateurs et aux rôles IAM l'accès à Kubernetes APIs](grant-k8s-access.md)** : découvrez comment permettre à des applications ou des utilisateurs de s’authentifier auprès de l’API Kubernetes. Vous pouvez utiliser des entrées d'accès, l'aws-auth ou un ConfigMap fournisseur OIDC externe.
**[Consultez les ressources Kubernetes dans le AWS Management Console](view-kubernetes-resources.md)**— Découvrez comment configurer le AWS Management Console pour communiquer avec votre cluster Amazon EKS. Utilisez la console pour consulter les ressources Kubernetes du cluster, telles que les espaces de noms, les nœuds et les pods.
**[Accorder AWS aux services l'accès en écriture à Kubernetes APIs](mutate-kubernetes-resources.md)**— Découvrez les autorisations requises pour modifier les ressources Kubernetes.
** [Connexion de kubectl à un cluster EKS en créant un fichier kubeconfig](create-kubeconfig.md) ** : découvrez comment configurer kubectl pour communiquer avec votre cluster Amazon EKS. Utilisez la AWS CLI pour créer un fichier kubeconfig.
**[Accorder aux charges de travail Kubernetes l’accès à AWS à l’aide des comptes de service Kubernetes](service-accounts.md)**— Découvrez comment associer un compte de service Kubernetes à IAM Roles AWS . Vous pouvez utiliser les rôles d’identité du pod ou IAM pour les comptes de service (IRSA).
## Tâches courantes
+ Accordez aux développeurs l’accès à l’API Kubernetes. Consultez les ressources Kubernetes dans le. AWS Management Console
+ Solution : [utilisez des entrées d'accès](access-entries.md) pour associer les autorisations Kubernetes RBAC aux utilisateurs ou aux rôles AWS IAM.
+ Configurez kubectl pour communiquer avec un cluster Amazon EKS à l'aide AWS des informations d'identification.
+ Solution : utilisez la AWS CLI pour [créer un fichier kubeconfig](create-kubeconfig.md).
+ Utilisez un fournisseur d’identité externe, comme Ping Identity, pour authentifier les utilisateurs auprès de l’API Kubernetes.
+ Solution : [associez un fournisseur OIDC externe](authenticate-oidc-identity-provider.md).
+ Donnez aux charges de travail de votre cluster Kubernetes la possibilité d'appeler. AWS APIs
+ Solution : [utilisez Pod Identity](pod-identities.md) pour associer un rôle AWS IAM à un compte de service Kubernetes.
## Contexte
+ [Découvrez comment fonctionnent les comptes de service Kubernetes.](https://kubernetes.io/docs/concepts/security/service-accounts/)
+ [Examen du modèle de contrôle d’accès basé sur les rôles (RBAC) de Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
+ Pour plus d'informations sur la gestion de l'accès aux AWS ressources, consultez le [guide de l'utilisateur AWS IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/intro-structure.html). Vous pouvez également suivre une [formation d'introduction gratuite sur l'utilisation d' AWS IAM](https://explore.skillbuilder.aws/learn/course/external/view/elearning/120/introduction-to-aws-identity-and-access-management-iam).
## Considérations relatives au mode automatique EKS
Le mode automatique EKS s’intègre à l’identité du pod EKS ainsi qu’aux entrées d’accès EKS.
+ Le mode automatique EKS utilise les entrées d’accès pour accorder au plan de contrôle EKS des autorisations Kubernetes. Par exemple, les stratégies d’accès permettent au mode automatique EKS de lire les informations concernant les points de terminaison réseau et les services.
+ Vous ne pouvez pas désactiver les entrées d’accès sur un cluster du mode automatique EKS.
+ Vous pouvez éventuellement activer le `ConfigMap` `aws-auth`.
+ Les entrées d’accès pour le mode automatique EKS sont configurées automatiquement. Vous pouvez consulter ces entrées d’accès, mais vous ne pouvez pas les modifier.
+ Si vous utilisez un NodeClass pour créer un rôle Node IAM personnalisé, vous devez créer une entrée d'accès pour le rôle conformément à la politique EKSAuto NodePolicy d'accès Amazon.
+ Si vous souhaitez accorder des autorisations aux charges de travail pour les AWS services, utilisez EKS Pod Identity.
+ Il n’est pas nécessaire d’installer l’agent d’identité du pod sur les clusters du mode automatique EKS.
# Accorder aux utilisateurs et aux rôles IAM l'accès à Kubernetes APIs
Votre cluster dispose d’un point de terminaison API Kubernetes. Kubectl utilise cette API. Vous pouvez vous authentifier auprès de cette API à l’aide de deux types d’identités :
+ **Un responsable de la gestion des AWS identités et des accès (IAM) (rôle ou utilisateur)** *: ce type nécessite une authentification auprès d'IAM.* Les utilisateurs peuvent se connecter en AWS tant qu'utilisateur [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) ou avec une [identité fédérée](https://aws.amazon.com/identity/federation/) en utilisant les informations d'identification fournies par le biais d'une source d'identité. Les utilisateurs ne peuvent se connecter qu'avec une identité fédérée si votre administrateur a précédemment configuré une fédération d'identité avec des rôles IAM. Lorsque les utilisateurs accèdent AWS par le biais de la fédération, ils [assument indirectement un rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/when-to-use-iam.html#security-iam-authentication-iamrole). Lorsque les utilisateurs utilisent ce type d'identité :
+ Vous pouvez leur attribuer des autorisations Kubernetes afin qu’ils puissent travailler avec les objets Kubernetes sur votre cluster. Pour plus d’informations sur la manière d’attribuer des autorisations à vos principaux IAM afin qu’ils puissent accéder aux objets Kubernetes sur votre cluster, consultez [Attribution de l’accès Kubernetes aux utilisateurs IAM avec les entrées d’accès EKS](access-entries.md).
+ Vous pouvez leur attribuer des autorisations IAM afin qu'ils puissent travailler avec votre cluster Amazon EKS et ses ressources à l'aide de l'API, de la AWS CLI AWS CloudFormation AWS Management Console, ou `eksctl` d'Amazon EKS. Pour plus d'informations, consultez la rubrique [Actions définies par Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) dans la Référence des autorisations de service.
+ Les nœuds rejoignent votre cluster en endossant un rôle IAM. La possibilité d’accéder à votre cluster à l’aide des principaux IAM est fournie par [l’authentificateur AWS IAM pour Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme), qui s’exécute sur le plan de contrôle Amazon EKS.
+ **Un utilisateur de votre propre fournisseur OpenID Connect (OIDC)** : ce type nécessite une authentification auprès de votre fournisseur [OIDC](https://openid.net/connect/). Pour plus d’informations sur la configuration de votre propre fournisseur OIDC avec votre cluster Amazon EKS, consultez [Accès des utilisateurs à Kubernetes via un fournisseur OIDC externe](authenticate-oidc-identity-provider.md). Lorsque les utilisateurs utilisent ce type d'identité :
+ Vous pouvez leur attribuer des autorisations Kubernetes afin qu’ils puissent travailler avec les objets Kubernetes sur votre cluster.
+ Impossible de leur attribuer des autorisations IAM afin qu'ils puissent travailler avec votre cluster Amazon EKS et ses ressources à l'aide de l'API, de la AWS CLI ou `eksctl` de Amazon EKS. AWS CloudFormation AWS Management Console
Vous pouvez utiliser les deux types d'identités avec votre cluster. La méthode d’authentification IAM ne peut pas être désactivée. La méthode d’authentification OIDC est facultative.
## Associer les identités IAM aux autorisations Kubernetes
[L’authentificateur AWS IAM pour Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme) est installé sur le plan de contrôle de votre cluster. Il active les [principaux de gestion des identités et des accès (IAM)AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) (rôles et utilisateurs) que vous autorisez à accéder aux ressources Kubernetes sur votre cluster. Vous pouvez autoriser les principaux IAM à accéder aux objets Kubernetes sur votre cluster à l’aide de l’une des méthodes suivantes :
+ **Création d’entrées d’accès** : si votre cluster est à la version de plate-forme indiquée dans la section [Conditions préalables](access-entries.md) pour la version Kubernetes de votre cluster ou à une version ultérieure, nous vous recommandons d’utiliser cette option.
Utilisez les *entrées d’accès* pour gérer les autorisations Kubernetes des principaux IAM depuis l’extérieur du cluster. Vous pouvez ajouter et gérer l'accès au cluster à l'aide de l'API EKS, de l'interface de ligne de AWS commande AWS SDKs AWS CloudFormation,, et AWS Management Console. Cela signifie que vous pouvez gérer les utilisateurs avec les mêmes outils que ceux avec lesquels vous avez créé le cluster.
Pour commencer, suivez [Changer le mode d'authentification pour utiliser les entrées d'accès](setting-up-access-entries.md), puis [Migration des entrées aws-auth existantes pour accéder aux ConfigMap entrées](migrating-access-entries.md).
+ **Ajouter des entrées au `aws-auth` `ConfigMap`** : si la version de plateforme de votre cluster est antérieure à celle indiquée dans la section [Prérequis](access-entries.md), vous devez utiliser cette option. Si la version de plateforme de votre cluster est égale ou supérieure à la version de plateforme indiquée dans la section [Conditions préalables](access-entries.md) pour la version Kubernetes de votre cluster, et que vous avez ajouté des entrées au fichier `ConfigMap`, nous vous recommandons de migrer ces entrées vers les entrées d’accès. Vous ne pouvez toutefois pas migrer les entrées qu’Amazon EKS a ajoutées à la `ConfigMap`, telles que les entrées pour les rôles IAM utilisés avec des groupes de nœuds gérés ou des profils Fargate. Pour de plus amples informations, veuillez consulter [Accorder aux utilisateurs et aux rôles IAM l'accès à Kubernetes APIs](#grant-k8s-access).
+ Si vous devez utiliser l'option `ConfigMap` `aws-auth`, vous pouvez ajouter des entrées à la `ConfigMap` à l'aide de la commande `eksctl create iamidentitymapping`. Pour plus d'informations, consultez la section [Gérer les utilisateurs et les rôles IAM](https://eksctl.io/usage/iam-identity-mappings/) dans la documentation `eksctl`.
## Définition du mode d’authentification du cluster
Chaque cluster possède un *mode d'authentification*. Le mode d’authentification détermine les méthodes que vous pouvez utiliser pour autoriser les principaux IAM à accéder aux objets Kubernetes de votre cluster. Il existe trois modes d'authentification.
**Important**
Une fois la méthode d’accès activée, elle ne peut plus être désactivée.
Si la méthode `ConfigMap` n’est pas activée lors de la création du cluster, elle ne peut pas être activée ultérieurement. Tous les clusters créés avant l’introduction des entrées d’accès ont cette méthode `ConfigMap` activée.
Si vous utilisez des nœuds hybrides avec votre cluster, vous devez utiliser les modes d’authentification ou cluster `API` ou `API_AND_CONFIG_MAP`.
**Le `aws-auth` `ConfigMap` à l’intérieur du cluster**
Il s'agit du mode d'authentification d'origine pour les clusters Amazon EKS. Le principal IAM qui a créé le cluster est l'utilisateur initial à avoir accès au cluster au moyen de `kubectl`. L'utilisateur initial doit ajouter d'autres utilisateurs à la liste dans la `ConfigMap` `aws-auth` et attribuer des autorisations qui affectent les autres utilisateurs au sein du cluster. Ces autres utilisateurs ne peuvent pas gérer ou supprimer l’utilisateur initial, car il n’y a aucune entrée à gérer dans la `ConfigMap`.
**À la fois le `ConfigMap` et les entrées d’accès**
Avec ce mode d'authentification, vous pouvez utiliser les deux méthodes pour ajouter des principaux IAM au cluster. Notez que chaque méthode stocke des entrées distinctes ; par exemple, si vous ajoutez une entrée d'accès depuis la AWS CLI, elle n'`aws-auth``ConfigMap`est pas mise à jour.
**Accès aux entrées uniquement**
Avec ce mode d'authentification, vous pouvez utiliser l'API EKS, l'interface de ligne de AWS commande AWS SDKs, AWS CloudFormation, et AWS Management Console pour gérer l'accès au cluster pour les principaux IAM.
Chaque entrée d'accès possède un *type* et vous pouvez utiliser la combinaison d'une *portée d'accès* pour limiter le principal à un espace de noms spécifique et d'une *stratégie d'accès* pour définir des politiques d'autorisations réutilisables préconfigurées. Vous pouvez également utiliser le type STANDARD et les groupes RBAC Kubernetes pour attribuer des autorisations personnalisées.
| Mode d’authentification | Méthodes |
| --- | --- |
| `ConfigMap` uniquement (`CONFIG_MAP`) | `aws-auth` `ConfigMap` |
| API EKS et `ConfigMap` (`API_AND_CONFIG_MAP`) | accéder aux entrées dans l'API EKS, l'interface de ligne de AWS commande AWS SDKs AWS CloudFormation,, AWS Management Console et `aws-auth` `ConfigMap` |
| API EKS uniquement (`API`) | accéder aux entrées de l'API EKS, de l'interface de ligne de AWS commande AWS SDKs AWS CloudFormation, et AWS Management Console |
**Note**
Le mode automatique Amazon EKS nécessite des entrées d’accès.
# Attribution de l’accès Kubernetes aux utilisateurs IAM avec les entrées d’accès EKS
Cette section explique comment gérer l’accès des principaux IAM aux clusters Kubernetes dans Amazon Elastic Kubernetes Service (EKS) en utilisant les entrées d’accès et des politiques d’accès. Vous y trouverez des informations sur la modification des modes d’authentification, la migration depuis les entrées `aws-auth` ConfigMap héritées, la création, la mise à jour et la suppression d’entrées d’accès, l’association de politiques aux entrées, la consultation des autorisations des politiques prédéfinies, et les prérequis et les considérations clés pour une gestion sécurisée des accès.
## Présentation
Les entrées d’accès EKS constituent la meilleure méthode pour accorder aux utilisateurs l’accès à l’API Kubernetes. Par exemple, vous pouvez utiliser les entrées d’accès pour permettre aux développeurs d’utiliser kubectl. Concrètement, une entrée d’accès EKS associe un ensemble d’autorisations Kubernetes à une identité IAM, comme un rôle IAM. Par exemple, un développeur peut assumer un rôle IAM et l’utiliser pour s’authentifier auprès d’un cluster EKS.
## Fonctionnalités
+ **Authentification et autorisation centralisées** : contrôle l’accès aux clusters Kubernetes directement via les API Amazon EKS, supprimant la nécessité d’alterner entre les API AWS et les API Kubernetes pour gérer les autorisations des utilisateurs.
+ **Gestion granulaire des autorisations** : utilise des entrées d’accès et des politiques pour définir des permissions fines pour les principaux AWS IAM, notamment la possibilité de modifier ou de retirer l’accès cluster-admin au créateur du cluster.
+ **Intégration aux outils IaC** : prend en charge les outils d’infrastructure en tant que code, tels que AWS CloudFormation, Terraform et AWS CDK, pour définir la configuration des accès lors de la création du cluster.
+ **Restauration après une mauvaise configuration** : permet de restaurer l’accès au cluster via l’API Amazon EKS sans nécessiter d’accès direct à l’API Kubernetes.
+ **Réduction des frais généraux et sécurité améliorée** : centralise les opérations afin de réduire les frais généraux tout en tirant parti des fonctionnalités offertes AWS IAM, telles que la journalisation via CloudTrail et l’authentification multifacteur.
## Attachement des autorisations
Vous pouvez attacher des autorisations Kubernetes aux entrées d’accès de deux façons :
+ Utiliser une stratégie d’accès. Les stratégies d’accès sont des modèles prédéfinis d’autorisations Kubernetes, gérés par AWS. Pour de plus amples informations, consultez [Vérification des autorisations des stratégies d’accès](access-policy-permissions.md).
+ Référencer un groupe Kubernetes. Si vous associez une identité IAM à un groupe Kubernetes, vous pouvez créer des ressources Kubernetes qui accordent des autorisations à ce groupe. Pour plus d'informations, consultez [Utilisation de l'autorisation RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) dans la documentation Kubernetes.
## Considérations
Lorsque vous activez des entrées d’accès EKS pour des clusters existants, gardez à l’esprit les points suivants :
+ **Comportement des clusters existants** : pour les clusters créés avant l’introduction des entrées d’accès (ceux dont la version de plateforme initiale est antérieure à celle indiquée dans [Exigences de version de plateforme](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html)), EKS crée automatiquement une entrée d’accès reflétant les autorisations préexistantes. Cette entrée inclut l’identité IAM qui a créé le cluster, ainsi que les autorisations administratives accordées lors de la création du cluster.
+ **Gestion du ConfigMap `aws-auth` hérité** : si votre cluster utilise encore le ConfigMap `aws-auth` hérité pour la gestion des accès, seule l’entrée d’accès correspondant au créateur initial du cluster est automatiquement créée lors de l’activation des entrées d’accès. Les rôles ou autorisations supplémentaires ajoutés au ConfigMap (par exemple, rôles IAM personnalisés pour des développeurs ou des services) ne sont pas migrés automatiquement. Pour résoudre ce problème, créez manuellement les entrées d’accès correspondantes.
## Mise en route
1. Déterminez l’identité IAM et la stratégie d’accès que vous souhaitez utiliser.
+ [Vérification des autorisations des stratégies d’accès](access-policy-permissions.md)
1. Activez les entrées d’accès EKS sur votre cluster. Vérifiez que vous disposez d’une version de plateforme prise en charge.
+ [Modifier le mode d’authentification pour utiliser les entrées d’accès](setting-up-access-entries.md)
1. Créez une entrée d’accès qui associe une identité IAM à une autorisation Kubernetes.
+ [Créer des entrées d’accès](creating-access-entries.md)
1. Authentifiez-vous auprès du cluster à l’aide de l’identité IAM.
+ [Configuration de l’interface de ligne de commande AWS](install-awscli.md)
+ [Configuration de `kubectl` et `eksctl`](install-kubectl.md)
# Association des stratégies d’accès aux entrées d’accès
Vous pouvez attribuer une ou plusieurs stratégies d'accès à des *entrées d'accès* de *type* `STANDARD`. Amazon EKS accorde automatiquement aux autres types d'entrées d'accès les autorisations nécessaires pour fonctionner correctement dans votre cluster. Les stratégies d’accès Amazon EKS contiennent des autorisations Kubernetes et non des autorisations IAM. Avant d’associer une stratégie d’accès à une entrée d’accès, assurez-vous de bien comprendre les autorisations Kubernetes incluses dans chaque stratégie d’accès. Pour de plus amples informations, consultez [Vérification des autorisations des stratégies d’accès](access-policy-permissions.md). Si aucune stratégie d’accès ne correspond à vos besoins, n’associez pas de stratégie d’accès à l’entrée d’accès. À la place, indiquez un ou plusieurs *noms de groupes* pour l’entrée d’accès, puis créez et gérez les objets Kubernetes de contrôle d’accès basé sur les rôles. Pour de plus amples informations, consultez [Créer des entrées d’accès](creating-access-entries.md).
+ Une entrée d'accès existante. Pour en créer un, consultez [Créer des entrées d’accès](creating-access-entries.md).
+ Un rôle ou un utilisateur de gestion des identités et des accès AWS disposant des autorisations suivantes : `ListAccessEntries`, `DescribeAccessEntry`, `UpdateAccessEntry`, `ListAccessPolicies`, `AssociateAccessPolicy` et `DisassociateAccessPolicy`. Pour plus d’informations, consultez [Actions définies par Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) dans la *Référence des autorisations de service*.
Avant d'associer des stratégies d'accès à des entrées d'accès, tenez compte des exigences suivantes :
+ Vous pouvez associer plusieurs stratégies d'accès à chaque entrée d'accès, mais vous ne pouvez associer chaque politique à une entrée d'accès qu'une seule fois. Si vous associez plusieurs stratégies d’accès, le principal IAM lié à l’entrée d’accès dispose de toutes les autorisations incluses dans ces stratégies d’accès.
+ Vous pouvez étendre une stratégie d’accès à toutes les ressources d’un cluster ou en spécifiant le nom d’un ou de plusieurs espaces de noms Kubernetes. Vous pouvez utiliser des caractères génériques pour le nom d'un espace de noms. Par exemple, si vous souhaitez étendre une stratégie d'accès à tous les espaces de noms commençant par `dev-`, vous pouvez spécifier `dev-*` sous forme de nom d'espace de noms. Assurez-vous que les espaces de noms existent sur votre cluster et que votre orthographe correspond au nom réel de l'espace de noms du cluster. Amazon EKS ne vérifie ni l’orthographe, ni l’existence des espaces de noms indiqués dans votre cluster.
+ Vous pouvez modifier la *portée d'accès* d'une stratégie d'accès après l'avoir associée à une entrée d'accès. Si vous avez limité la stratégie d’accès aux espaces de noms Kubernetes, vous pouvez ajouter ou supprimer des espaces de noms de l’association selon les besoins.
+ Si vous associez une stratégie d'accès à une entrée d'accès dont les *noms de groupe* sont également spécifiés, le principal IAM dispose alors de toutes les autorisations dans toutes les stratégies d'accès associées. Il dispose également de toutes les autorisations dans n’importe quel objet Kubernetes `Role` ou `ClusterRole` spécifié dans n’importe quels objets Kubernetes `Role` et `RoleBinding` qui spécifient les noms de groupes.
+ Si vous exécutez la commande `kubectl auth can-i --list`, les autorisations accordées par les stratégies d’accès associées à une entrée d’accès n’apparaîtront pas pour le principal IAM utilisé lors de l’exécution de la commande. La commande n’affiche les autorisations Kubernetes que si vous les avez accordées dans des objets Kubernetes `Role` ou `ClusterRole` que vous avez liés aux noms de groupes ou au nom d’utilisateur spécifiés pour une entrée d’accès.
+ Si vous usurpez l’identité d’un utilisateur ou groupe Kubernetes lorsque vous interagissez avec les objets Kubernetes de votre cluster, par exemple en utilisant la commande `kubectl` avec `--as username ` ou `--as-group group-name `, vous forcez l’utilisation du mécanisme d’autorisation RBAC Kubernetes. Par conséquent, le principal IAM ne dispose d'aucune autorisation attribuée par les stratégies d'accès associées à l'entrée d'accès. Les seules autorisations Kubernetes dont dispose l’utilisateur ou le groupe dont l’identité est usurpée par le principal IAM sont celles que vous lui avez accordées dans les objets Kubernetes `Role` ou `ClusterRole` liés aux noms de groupes ou au nom d’utilisateur. Pour que votre principal IAM bénéficie des autorisations définies dans les stratégies d’accès associées à l’entrée d’accès, n’usurpez pas l’identité d’un utilisateur ou d’un groupe Kubernetes. Le principal IAM conserve également toute autorisation que vous lui avez accordée via des objets Kubernetes `Role` ou `ClusterRole` liés aux noms de groupes ou au nom d’utilisateur que vous avez définis pour l’entrée d’accès. Pour plus d’informations, consultez [Usurpation d’identité d’utilisateur](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) dans la documentation Kubernetes.
Vous pouvez associer une stratégie d’accès à une entrée d’accès à l’aide de la AWS Management Console ou de la CLI AWS.
## AWS Management Console
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Choisissez le nom du cluster qui possède une entrée d'accès à laquelle associer une stratégie d'accès.
1. Choisissez l'onglet **Access**.
1. Si le type d'entrée d'accès est **Standard**, vous pouvez associer ou dissocier les **stratégies d'accès** Amazon EKS. Si le type de votre entrée d’accès est différent de **Standard**, cette option n’est pas disponible.
1. Choisissez **Associer la stratégie d'accès**.
1. Dans **Nom de la stratégie**, sélectionnez la stratégie avec les autorisations que vous souhaitez attribuer au principal IAM. Pour consulter les autorisations incluses dans chaque stratégie, consultez [Vérification des autorisations des stratégies d’accès](access-policy-permissions.md).
1. Pour **Portée d'accès**, choisissez une portée d'accès. Si vous choisissez **Cluster**, les autorisations de la stratégie d’accès sont accordées au principal IAM pour tous les espaces de noms Kubernetes. Si vous choisissez **Espace de noms Kubernetes**, vous pouvez ensuite sélectionner **Ajouter un nouvel espace de noms**. Dans le champ **Espace de noms** qui s’affiche, saisissez le nom d’un espace de noms Kubernetes de votre cluster. Si vous souhaitez que le principal IAM dispose d'autorisations sur plusieurs espaces de noms, vous pouvez saisir plusieurs espaces de noms.
1. Choisissez **Ajouter une stratégie d'accès**.
## AWS CLI
1. Version `2.12.3` ou ultérieure ou version `1.27.160` ou ultérieure de l’interface de la ligne de commande AWS (AWS CLI) installée et configurée sur votre appareil ou dans AWS CloudShell. Pour vérifier votre version actuelle, utilisez `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Les gestionnaires de package tels que `yum`, `apt-get` ou Homebrew pour macOS ont souvent plusieurs versions de retard par rapport à la dernière version de l’AWS CLI. Pour installer la dernière version, consultez les sections [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) du *Guide de l’utilisateur de l’interface de la ligne de commande AWS*. La version de l’AWS CLI installée dans AWS CloudShell peut également être plusieurs versions derrière la dernière version. Pour la mettre à jour, consultez la section [Installation de l’AWS CLI dans votre répertoire personnel](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) dans le *Guide de l’utilisateur AWS CloudShell*.
1. Affichez les stratégies d'accès disponibles.
```
aws eks list-access-policies --output table
```
L'exemple qui suit illustre un résultat.
```
---------------------------------------------------------------------------------------------------------
| ListAccessPolicies |
+-------------------------------------------------------------------------------------------------------+
|| accessPolicies ||
|+---------------------------------------------------------------------+-------------------------------+|
|| arn | name ||
|+---------------------------------------------------------------------+-------------------------------+|
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSAdminPolicy | AmazonEKSAdminPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy | AmazonEKSClusterAdminPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSEditPolicy | AmazonEKSEditPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSViewPolicy | AmazonEKSViewPolicy ||
|+---------------------------------------------------------------------+-------------------------------+|
```
Pour consulter les autorisations incluses dans chaque stratégie, consultez [Vérification des autorisations des stratégies d’accès](access-policy-permissions.md).
1. Consultez vos entrées d'accès existantes. Remplacez *my-cluster* par le nom de votre cluster.
```
aws eks list-access-entries --cluster-name my-cluster
```
L'exemple qui suit illustre un résultat.
```
{
"accessEntries": [
"arn:aws:iam::111122223333:role/my-role",
"arn:aws:iam::111122223333:user/my-user"
]
}
```
1. Associez une stratégie d'accès à une entrée d'accès. L'exemple suivant associe la stratégie d'accès `AmazonEKSViewPolicy` à une entrée d'accès. Chaque fois que le rôle IAM *my-role* tente d’accéder aux objets Kubernetes du cluster, Amazon EKS autorise ce rôle à utiliser les autorisations définies dans la stratégie d’accès uniquement pour les objets Kubernetes situés dans les espaces de noms *my-namespace1* et *my-namespace2*. Remplacez *my-cluster* par le nom de votre cluster, *111122223333* par l’ID de votre compte AWS et *my-role* par le nom du rôle IAM pour lequel vous souhaitez qu’Amazon EKS autorise l’accès aux objets du cluster Kubernetes.
```
aws eks associate-access-policy --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role \
--access-scope type=namespace,namespaces=my-namespace1,my-namespace2 --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy
```
Si vous souhaitez que le principal IAM dispose des autorisations à l'échelle du cluster, remplacez `type=namespace,namespaces=my-namespace1,my-namespace2 ` par `type=cluster`. Si vous souhaitez associer plusieurs stratégies d'accès à l'entrée d'accès, exécutez la commande plusieurs fois, chaque fois avec une stratégie d'accès unique. Chaque stratégie d'accès associée possède sa propre portée.
**Note**
Si vous souhaitez ultérieurement modifier la portée d'une stratégie d'accès associée, réexécutez la commande précédente avec la nouvelle portée. Par exemple, si vous souhaitez supprimer *my-namespace2*, vous devez réexécuter la commande en utilisant uniquement `type=namespace,namespaces=my-namespace1 `. Si vous souhaitez modifier la portée de `namespace` à `cluster`, vous devez exécuter à nouveau la commande en utilisant `type=cluster`, ce qui supprime `type=namespace,namespaces=my-namespace1,my-namespace2 `.
1. Déterminez les stratégies d'accès associées à une entrée d'accès.
```
aws eks list-associated-access-policies --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role
```
L'exemple qui suit illustre un résultat.
```
{
"clusterName": "my-cluster",
"principalArn": "arn:aws:iam::111122223333",
"associatedAccessPolicies": [
{
"policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy",
"accessScope": {
"type": "cluster",
"namespaces": []
},
"associatedAt": "2023-04-17T15:25:21.675000-04:00",
"modifiedAt": "2023-04-17T15:25:21.675000-04:00"
},
{
"policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy",
"accessScope": {
"type": "namespace",
"namespaces": [
"my-namespace1",
"my-namespace2"
]
},
"associatedAt": "2023-04-17T15:02:06.511000-04:00",
"modifiedAt": "2023-04-17T15:02:06.511000-04:00"
}
]
}
```
Dans l’exemple précédent, le principal IAM associé à cette entrée d’accès dispose d’autorisations de lecture sur tous les espaces de noms du cluster et d’autorisations administrateur sur deux espaces de noms Kubernetes.
1. Dissociez une stratégie d'accès d'une entrée d'accès. Dans cet exemple, la stratégie `AmazonEKSAdminPolicy` est dissociée d'une entrée d'accès. Le principal IAM conserve toutefois les autorisations définies dans la stratégie d'accès `AmazonEKSViewPolicy` pour les objets des espaces de noms *my-namespace1* et *my-namespace2*, car cette stratégie d'accès n'est pas dissociée de l'entrée d'accès.
```
aws eks disassociate-access-policy --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy
```
Pour répertorier toutes les stratégies d’accès disponibles, consultez [Vérification des autorisations des stratégies d’accès](access-policy-permissions.md).
# Migration des entrées `aws-auth ConfigMap` existantes pour accéder aux entrées
Si vous avez ajouté des entrées de `ConfigMap` `aws-auth` à votre cluster, nous vous recommandons de créer des entrées d’accès pour les entrées existantes dans votre cluster `ConfigMap` `aws-auth`. Après avoir créé les entrées d'accès, vous pouvez les supprimer de votre `ConfigMap`. Vous ne pouvez pas associer de [stratégies d’accès](access-policies.md) aux entrées dans la `ConfigMap` `aws-auth`. Si vous souhaitez associer des stratégies d'accès à vos principaux IAM, créez des entrées d'accès.
**Important**
Lorsqu’un cluster est en mode d’authentification `API_AND_CONFIGMAP` et qu’il existe un mappage pour le même rôle IAM dans les `aws-auth` `ConfigMap` et dans les entrées d’accès, le rôle utilisera le mappage de l’entrée d’accès pour l’authentification. Les entrées d’accès ont priorité sur les entrées `ConfigMap` pour le même principal IAM.
Avant de supprimer les entrées `aws-auth` `ConfigMap` existantes créées par Amazon EKS pour le [groupe de nœuds](managed-node-groups.md) gérés ou un [profil Fargate](fargate-profile.md) vers votre cluster, vérifiez que les entrées d’accès correctes pour ces ressources spécifiques existent dans votre cluster Amazon EKS. Si vous supprimez les entrées créées par Amazon EKS dans le `ConfigMap` sans disposer des entrées d’accès équivalentes, votre cluster ne fonctionnera pas correctement.
## Conditions préalables
+ Avoir des connaissances sur les entrées d'accès et les stratégies d'accès. Pour plus d’informations, consultez [Attribution de l’accès Kubernetes aux utilisateurs IAM avec les entrées d’accès EKS](access-entries.md) et [Association des stratégies d’accès aux entrées d’accès](access-policies.md).
+ Un cluster existant avec une version de plateforme égale ou supérieure aux versions répertoriées dans les conditions préalables de la rubrique [Attribution de l’accès Kubernetes aux utilisateurs IAM avec les entrées d’accès EKS](access-entries.md).
+ 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`.
+ Autorisations Kubernetes permettant de modifier le `aws-auth` `ConfigMap` dans l’espace de noms `kube-system`.
+ Un rôle ou un utilisateur AWS Identity and Access Management disposant des autorisations suivantes : `CreateAccessEntry` et`ListAccessEntries`. Pour plus d'informations, consultez la rubrique [Actions définies par Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) dans la Référence des autorisations de service.
## `eksctl`
1. Consultez les entrées existantes dans votre `aws-auth ConfigMap`. Remplacez *my-cluster* par le nom de votre cluster.
```
eksctl get iamidentitymapping --cluster my-cluster
```
L'exemple qui suit illustre un résultat.
```
ARN USERNAME GROUPS ACCOUNT
arn:aws: iam::111122223333:role/EKS-my-cluster-Admins Admins system:masters
arn:aws: iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers my-namespace-Viewers Viewers
arn:aws: iam::111122223333:role/EKS-my-cluster-self-managed-ng-1 system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
arn:aws: iam::111122223333:user/my-user my-user
arn:aws: iam::111122223333:role/EKS-my-cluster-fargateprofile1 system:node:{{SessionName}} system:bootstrappers,system:nodes,system:node-proxier
arn:aws: iam::111122223333:role/EKS-my-cluster-managed-ng system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
```
1. [Créer des entrées d’accès](creating-access-entries.md) pour toutes les entrées `ConfigMap` que vous avez créées et qui apparaissent dans la sortie précédente. Lorsque vous créez les entrées d'accès, assurez-vous de spécifier les mêmes valeurs pour `ARN`, `USERNAME`, `GROUPS` et `ACCOUNT` et de les renvoyer dans votre résultat. Dans l'exemple de résultat, vous devez créer des entrées d'accès pour toutes les entrées sauf les deux dernières, étant donné que ces entrées ont été créées par Amazon EKS pour un profil Fargate et un groupe de nœuds géré.
1. Supprimez les entrées de la `ConfigMap` pour toutes les entrées d'accès que vous avez créées. Si vous ne supprimez pas l’entrée de la `ConfigMap`, les paramètres de l’entrée d’accès pour l’ARN principal IAM remplaceront l’entrée `ConfigMap`. *111122223333*Remplacez-le par votre numéro de AWS compte et *EKS-my-cluster-my-namespace-Viewers* par le nom du rôle dans l'entrée de votre`ConfigMap`. Si l'entrée que vous supprimez concerne un utilisateur IAM plutôt qu'un rôle IAM, remplacez-la par `user` et `role` *EKS-my-cluster-my-namespace-Viewers* par le nom d'utilisateur.
```
eksctl delete iamidentitymapping --arn arn:aws: iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers --cluster my-cluster
```
# Vérification des autorisations des stratégies d’accès
Les stratégies d’accès incluent des `rules` qui contiennent des `verbs` (autorisations) et des `resources` Kubernetes. Les stratégies d’accès n’incluent pas d’autorisations IAM ni de ressources IAM. Similaires aux objets Kubernetes `Role` et `ClusterRole`, les stratégies d’accès ne contiennent que des `rules` `allow`. Vous ne pouvez pas modifier le contenu d’une stratégie d’accès. Vous ne pouvez pas créer vos propres stratégies d’accès. Si les autorisations fournies par les stratégies d’accès ne correspondent pas à vos besoins, créez des objets RBAC Kubernetes et indiquez des *noms de groupes* dans vos entrées d’accès. Pour de plus amples informations, veuillez consulter [Créer des entrées d’accès](creating-access-entries.md). Les autorisations définies dans les stratégies d’accès sont similaires à celles fournies par les rôles de cluster Kubernetes destinés aux utilisateurs. Pour plus d’informations, consultez la section [Rôles destinés aux utilisateurs](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) dans la documentation Kubernetes.
## Liste de toutes les stratégies
Utilisez l'une des politiques d'accès répertoriées sur cette page ou récupérez la liste de toutes les politiques d'accès disponibles à l'aide de la AWS CLI :
```
aws eks list-access-policies
```
Le résultat attendu doit ressembler à ceci (abrégé par souci de concision) :
```
{
"accessPolicies": [
{
"name": "AmazonAIOpsAssistantPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonAIOpsAssistantPolicy"
},
{
"name": "AmazonARCRegionSwitchScalingPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonARCRegionSwitchScalingPolicy"
},
{
"name": "AmazonEKSAdminPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy"
},
{
"name": "AmazonEKSAdminViewPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminViewPolicy"
},
{
"name": "AmazonEKSAutoNodePolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy"
}
// Additional policies omitted
]
}
```
## EKSAdminPolitique d'Amazon
Cette stratégie d'accès inclut des autorisations qui accordent à un principal IAM le plus grand nombre d'autorisations sur les ressources. Lorsqu’elle est associée à une entrée d’accès, sa portée d’accès correspond généralement à un ou plusieurs espaces de noms Kubernetes. Si vous souhaitez qu'un principal IAM dispose d'un accès administrateur à toutes les ressources de votre cluster, associez plutôt la stratégie d'accès [Amazon EKSCluster AdminPolicy](#access-policy-permissions-amazoneksclusteradminpolicy) à votre entrée d'accès.
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSAdminPolicy`
| Groupes d’API Kubernetes | Ressources Kubernetes | Verbes (autorisations) Kubernetes |
| --- | --- | --- |
| `apps` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `replicasets`, `replicasets/scale`, `statefulsets`, `statefulsets/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `authorization.k8s.io` | `localsubjectaccessreviews` | `create` |
| `autoscaling` | `horizontalpodautoscalers` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `batch` | `cronjobs`, `jobs` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `ingresses`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicationcontrollers/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `networkpolicies` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| `rbac.authorization.k8s.io` | `rolebindings`, `roles` | `create`, `delete`, `deletecollection`, `get`, `list`, `patch`, `update`, `watch` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`,`list`, `watch` |
| | `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy`, `secrets`, `services/proxy` | `get`, `list`, `watch` |
| | `configmaps`, `events`, `persistentvolumeclaims`, `replicationcontrollers`, `replicationcontrollers/scale`, `secrets`, `serviceaccounts`, `services`, `services/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `pods`, `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `serviceaccounts` | `impersonate` |
| | `bindings`, `events`, `limitranges`, `namespaces/status`, `pods/log`, `pods/status`, `replicationcontrollers/status`, `resourcequotas`, `resourcequotas/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`,`list`, `watch` |
## Amazon EKSCluster AdminPolicy
Cette stratégie d'accès inclut des autorisations qui accordent à un administrateur principal IAM l'accès à un cluster. Lorsqu’elle est associée à une entrée d’accès avec portée Cluster, sa portée concerne l’ensemble du cluster, plutôt qu’un espace de noms unique. Si vous souhaitez qu'un principal IAM ait une portée administrative plus limitée, pensez plutôt à associer la stratégie d'accès [EKSAdminPolitique d'Amazon](#access-policy-permissions-amazoneksadminpolicy) à votre entrée d'accès.
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy`
| Groupes d’API Kubernetes | Kubernetes Non-Resource URLs | Ressources Kubernetes | Verbes (autorisations) Kubernetes |
| --- | --- | --- | --- |
| `*` | | `*` | `*` |
| | `*` | | `*` |
## Amazon EKSAdmin ViewPolicy
Cette politique d'accès inclut des autorisations qui accordent à un IAM principal l'accès à list/view toutes les ressources d'un cluster. Notez que cela inclut les [secrets Kubernetes](https://kubernetes.io/docs/concepts/configuration/secret/).
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSAdminViewPolicy`
| Groupes d’API Kubernetes | Ressources Kubernetes | Verbes (autorisations) Kubernetes |
| --- | --- | --- |
| `*` | `*` | `get`, `list`, `watch` |
## EKSEditPolitique d'Amazon
Cette stratégie d’accès inclut des autorisations permettant à un principal IAM de modifier la plupart des ressources Kubernetes.
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSEditPolicy`
| Groupes d’API Kubernetes | Ressources Kubernetes | Verbes (autorisations) Kubernetes |
| --- | --- | --- |
| `apps` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `replicasets`, `replicasets/scale`, `statefulsets`, `statefulsets/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `jobs` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `ingresses`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicationcontrollers/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `networkpolicies` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `policy` | `poddisruptionbudgets` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`, `list`, `watch` |
| | `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy`, `secrets`, `services/proxy` | `get`, `list`, `watch` |
| | `serviceaccounts` | `impersonate` |
| | `pods`, `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `configmaps`, `events`, `persistentvolumeclaims`, `replicationcontrollers`, `replicationcontrollers/scale`, `secrets`, `serviceaccounts`, `services`, `services/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`, `list`, `watch` |
| | `bindings`, `events`, `limitranges`, `namespaces/status`, `pods/log`, `pods/status`, `replicationcontrollers/status`, `resourcequotas`, `resourcequotas/status` | `get`, `list`, `watch` |
## EKSViewPolitique d'Amazon
Cette stratégie d’accès inclut des autorisations permettant à un principal IAM de consulter la plupart des ressources Kubernetes.
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSViewPolicy`
| Groupes d’API Kubernetes | Ressources Kubernetes | Verbes (autorisations) Kubernetes |
| --- | --- | --- |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`, `list`, `watch` |
| | `bindings`, `events`, `limitranges`, `namespaces/status`, `pods/log`, `pods/status`, `replicationcontrollers/status`, `resourcequotas`, r`esourcequotas/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`, `list`, `watch` |
## Amazon EKSSecret ReaderPolicy
Cette politique d'accès inclut des autorisations qui permettent à un principal IAM de lire les secrets [Kubernetes](https://kubernetes.io/docs/concepts/configuration/secret/).
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSSecretReaderPolicy`
| Groupes d’API Kubernetes | Ressources Kubernetes | Verbes (autorisations) Kubernetes |
| --- | --- | --- |
| | `secrets` | `get`, `list`, `watch` |
## Amazon EKSAuto NodePolicy
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy`
Cette stratégie inclut les autorisations suivantes, permettant aux composants Amazon EKS d’accomplir les tâches suivantes :
+ `kube-proxy` : surveiller les points de terminaison réseau et les services, et gérer les événements associés. Cela permet d’activer la fonctionnalité de proxy réseau à l’échelle du cluster.
+ `ipamd`— Gérez les ressources réseau AWS VPC et les interfaces réseau de conteneurs (CNI). Cela permet au démon de gestion des adresses IP de gérer le réseau des pods.
+ `coredns` : accéder aux ressources de découverte de services telles que les points de terminaison et les services. Cela permet la résolution DNS au sein du cluster.
+ `ebs-csi-driver` : gérer les ressources liées au stockage pour les volumes Amazon EBS. Cela permet le provisionnement dynamique et l’attachement des volumes persistants.
+ `neuron`— Surveillez les nœuds et les pods des appareils AWS Neuron. Cela permet de gérer les accélérateurs AWS Inferentia et Trainium.
+ `node-monitoring-agent` : accéder aux diagnostics et événements des nœuds. Cela permet la surveillance de l’état du cluster et la collecte des diagnostics.
Chaque composant utilise un compte de service dédié et ne dispose que des autorisations nécessaires à sa fonction spécifique.
Si vous spécifiez manuellement un rôle Node IAM dans un NodeClass, vous devez créer une entrée d'accès qui associe le nouveau rôle Node IAM à cette politique d'accès.
## Amazon EKSBlock StoragePolicy
**Note**
Cette politique s'applique uniquement aux rôles AWS liés aux services et ne peut pas être utilisée avec des rôles gérés par le client.
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSBlockStoragePolicy`
Cette stratégie inclut des autorisations permettant à Amazon EKS de gérer l’élection du leader et les ressources de coordination pour les opérations de stockage :
+ `coordination.k8s.io` : créer et gérer des objets Lease pour l’élection du leader. Cela permet aux composants de stockage EKS de coordonner leurs opérations dans tout le cluster grâce à un mécanisme d’élection du leader.
La stratégie est limitée à des ressources de location spécifiques utilisées par les composants de stockage EKS, afin d’éviter tout conflit d’accès avec d’autres ressources de coordination présentes dans le cluster.
Amazon EKS crée automatiquement une entrée d’accès avec cette stratégie d’accès pour le rôle IAM du cluster lorsque le mode automatique est activé, garantissant que les autorisations nécessaires sont en place pour que la fonctionnalité de stockage par blocs fonctionne correctement.
## Amazon EKSLoad BalancingPolicy
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSLoadBalancingPolicy`
Cette stratégie inclut des autorisations qui permettent à Amazon EKS de gérer les ressources d’élection du leader pour l’équilibrage de charge :
+ `coordination.k8s.io` : créer et gérer des objets Lease pour l’élection du leader. Cela permet aux composants d’équilibrage de charge EKS de coordonner leurs activités entre plusieurs réplicas grâce à l’élection d’un leader.
La stratégie est limitée aux ressources de location dédiées à l’équilibrage de charge afin d’assurer une bonne coordination, tout en empêchant l’accès à d’autres ressources de location du cluster.
Amazon EKS crée automatiquement une entrée d’accès avec cette stratégie d’accès pour le rôle IAM du cluster lorsque le mode automatique est activé, garantissant que les autorisations nécessaires sont en place pour que la fonctionnalité réseau fonctionne correctement.
## EKSNetworkingPolitique d'Amazon
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSNetworkingPolicy`
Cette stratégie inclut des autorisations qui permettent à Amazon EKS de gérer les ressources d’élection du leader pour les opérations réseau :
+ `coordination.k8s.io` : créer et gérer des objets Lease pour l’élection du leader. Cela permet aux composants réseau EKS de coordonner les activités d’allocation d’adresses IP grâce à l’élection d’un leader.
La stratégie est limitée aux ressources de location dédiées au réseau afin d’assurer une bonne coordination, tout en empêchant l’accès à d’autres ressources de location du cluster.
Amazon EKS crée automatiquement une entrée d’accès avec cette stratégie d’accès pour le rôle IAM du cluster lorsque le mode automatique est activé, garantissant que les autorisations nécessaires sont en place pour que la fonctionnalité réseau fonctionne correctement.
## EKSComputePolitique d'Amazon
**Note**
Cette politique s'applique uniquement aux rôles AWS liés aux services et ne peut pas être utilisée avec des rôles gérés par le client.
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSComputePolicy`
Cette stratégie inclut des autorisations permettant à Amazon EKS de gérer les ressources d’élection du leader pour les opérations de calcul :
+ `coordination.k8s.io` : créer et gérer des objets Lease pour l’élection du leader. Cela permet aux composants de calcul EKS de coordonner les activités de mise à l’échelle des nœuds grâce à l’élection d’un leader.
La stratégie est limitée aux ressources de location dédiées à la gestion du calcul, tout en autorisant un accès en lecture de base (`get`, `watch`) à toutes les ressources de location du cluster.
Amazon EKS crée automatiquement une entrée d’accès avec cette stratégie d’accès pour le rôle IAM du cluster lorsque le mode automatique est activé, garantissant que les autorisations nécessaires sont en place pour que la fonctionnalité réseau fonctionne correctement.
## Amazon EKSBlock StorageClusterPolicy
**Note**
Cette politique s'applique uniquement aux rôles AWS liés aux services et ne peut pas être utilisée avec des rôles gérés par le client.
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSBlockStorageClusterPolicy`
Cette politique accorde les autorisations nécessaires pour la fonctionnalité de stockage en blocs du mode automatique Amazon EKS. Elle permet une gestion efficace des ressources de stockage par blocs au sein des clusters Amazon EKS. La stratégie inclut les autorisations suivantes :
Gestion des pilotes CSI :
+ Créer, lire, mettre à jour et supprimer les pilotes CSI, spécifiquement pour le stockage par blocs.
Gestion des volumes :
+ Répertorier, surveiller, créer, mettre à jour, patcher et supprimer les volumes persistants.
+ Répertorier, surveiller et mettre à jour les demandes de volumes persistants.
+ Corriger l’état des demandes de volumes persistants.
Interaction entre les nœuds et les pods :
+ Lire les informations sur les nœuds et les pods.
+ Gérer les événements liés aux opérations de stockage.
Classes de stockage et attributs :
+ Lire les classes de stockage et les nœuds CSI.
+ Lire les classes d’attributs de volume.
Attachements de volumes :
+ Répertorier, surveiller et modifier les attachements de volumes et leurs statuts.
Opérations d’instantanés :
+ Gérer les instantanés de volumes, le contenu des instantanés et les classes d’instantanés.
+ Gérer les opérations pour les instantanés de groupes de volumes et les ressources associées.
Cette politique est conçue pour prendre en charge la gestion complète du stockage en blocs au sein des clusters Amazon EKS s’exécutant en mode automatique. Elle combine les autorisations nécessaires pour les opérations de provisionnement, attachement, redimensionnement et création d’instantanés de volumes de stockage par blocs.
Amazon EKS crée automatiquement une entrée d’accès avec cette stratégie d’accès pour le rôle IAM du cluster lorsque le mode automatique est activé, garantissant que les autorisations nécessaires sont en place pour que la fonctionnalité de stockage par blocs fonctionne correctement.
## Amazon EKSCompute ClusterPolicy
**Note**
Cette politique s'applique uniquement aux rôles AWS liés aux services et ne peut pas être utilisée avec des rôles gérés par le client.
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSComputeClusterPolicy`
Cette politique accorde les autorisations nécessaires à la fonctionnalité de gestion du calcul du mode automatique Amazon EKS. Elle permet une orchestration efficace et une mise à l’échelle des ressources de calcul au sein des clusters Amazon EKS. La stratégie inclut les autorisations suivantes :
Gestion des nœuds :
+ Créez, lisez, mettez à jour, supprimez et gérez le statut de NodePools et NodeClaims.
+ Gérez NodeClasses, y compris la création, la modification et la suppression.
Gestion de la planification et des ressources :
+ Accès en lecture aux pods, aux nœuds, aux volumes persistants, aux demandes de volumes persistants, aux contrôleurs de réplication et aux espaces de noms.
+ Accès en lecture aux classes de stockage, aux nœuds CSI et aux attachements de volumes.
+ Répertorier et surveiller les déploiements, les ensembles de démons, les ensembles de réplicas et les ensembles avec état.
+ Accès en lecture aux budgets d’interruption des pods.
Gestion des événements :
+ Créer, lire et gérer les événements du cluster.
Déprovisionnement des nœuds et éviction des pods :
+ Mettre à jour, corriger et supprimer des nœuds.
+ Créer des évictions de pods et supprimer des pods lorsque nécessaire.
Gestion des définitions de ressources personnalisées (CRD) :
+ Créez un nouveau CRDs.
+ Gérez les CRDs éléments spécifiques liés à la gestion des nœuds (NodeClasses NodePools NodeClaims,, et NodeDiagnostics).
Cette stratégie est conçue pour assurer une gestion complète des ressources de calcul au sein des clusters Amazon EKS exécutés en mode automatique. Elle regroupe les autorisations nécessaires pour des opérations telles que le provisionnement des nœuds, la planification, la mise à l’échelle et l’optimisation des ressources.
Amazon EKS crée automatiquement une entrée d’accès avec cette stratégie d’accès pour le rôle IAM du cluster lorsque le mode automatique est activé, garantissant ainsi que les autorisations nécessaires à la gestion du calcul sont correctement appliquées.
## Amazon EKSLoad BalancingClusterPolicy
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSLoadBalancingClusterPolicy`
Cette stratégie accorde les autorisations nécessaires pour la fonctionnalité d’équilibrage de charge du mode automatique Amazon EKS. Elle permet une gestion et une configuration efficaces des ressources d’équilibrage de charge au sein des clusters Amazon EKS. La stratégie inclut les autorisations suivantes :
Gestion des événements et des ressources :
+ Créer et corriger des événements.
+ Accès en lecture aux pods, aux nœuds, aux points de terminaison et aux espaces de noms.
+ Mettre à jour l’état des pods.
Gestion des ressources Service et Ingress :
+ Gestion complète des services et de leurs états.
+ Contrôle complet des ressources Ingress et de leurs états.
+ Accès en lecture aux tranches de points de terminaison et aux classes de ressources Ingress.
Liaisons de groupes cibles :
+ Créer et modifier les liaisons de groupes cibles et leurs états.
+ Accès en lecture aux paramètres de la classe de ressources Ingress.
Gestion des définitions de ressources personnalisées (CRD) :
+ Créez et lisez tout CRDs.
+ Gestion spécifique de targetgroupbindings.eks.amazonaws.com et ingressclassparams.eks.amazonaws.com. CRDs
Configuration des webhooks :
+ Créer et lire des configurations de webhooks de type mutant et validant.
+ Gérez la eks-load-balancing-webhook configuration.
Cette stratégie est conçue pour assurer une gestion complète de l’équilibrage de charge au sein des clusters Amazon EKS exécutés en mode automatique. Il combine des autorisations pour diverses opérations, notamment l'exposition aux services, le routage d'entrée et l'intégration aux services d'équilibrage de AWS charge.
Amazon EKS crée automatiquement une entrée d’accès associée à cette stratégie d’accès pour le rôle IAM du cluster lorsque le mode automatique est activé, garantissant ainsi que les autorisations nécessaires à la fonctionnalité d’équilibrage de charge sont correctement appliquées.
## Amazon EKSNetworking ClusterPolicy
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSNetworkingClusterPolicy`
Amazon EKSNetworking ClusterPolicy
Cette stratégie accorde les autorisations nécessaires à la fonctionnalité réseau du mode automatique Amazon EKS. Elle permet une gestion et une configuration efficaces des ressources réseau au sein des clusters Amazon EKS. La stratégie inclut les autorisations suivantes :
Gestion des nœuds et des pods :
+ Accès en lecture à NodeClasses et à leurs statuts.
+ Accès en lecture à NodeClaims et à leurs statuts.
+ Accès en lecture aux pods.
Gestion des nœuds CNI :
+ Les autorisations CNINodes et leur statut, y compris la création, la lecture, la mise à jour, la suppression et le correctif.
Gestion des définitions de ressources personnalisées (CRD) :
+ Créez et lisez tout CRDs.
+ Gestion spécifique (mise à jour, correction, suppression) de la CRD cninodes.eks.amazonaws.com.
Gestion des événements :
+ Créer et corriger des événements.
Cette stratégie est conçue pour assurer une gestion complète du réseau au sein des clusters Amazon EKS exécutés en mode automatique. Elle regroupe les autorisations nécessaires pour diverses opérations, incluant la configuration réseau des nœuds, la gestion CNI (Container Network Interface) et la gestion des ressources personnalisées liées au réseau.
La stratégie permet aux composants réseau d’interagir avec les ressources liées aux nœuds, de gérer les configurations spécifiques CNI des nœuds, et de traiter les ressources personnalisées essentielles aux opérations réseau dans le cluster.
Amazon EKS crée automatiquement une entrée d’accès avec cette stratégie d’accès pour le rôle IAM du cluster lorsque le mode automatique est activé, garantissant que les autorisations nécessaires sont en place pour que la fonctionnalité réseau fonctionne correctement.
## EKSHybridPolitique d'Amazon
**Note**
Cette politique s'applique uniquement aux rôles AWS liés aux services et ne peut pas être utilisée avec des rôles gérés par le client.
Cette stratégie d’accès inclut des autorisations qui permettent à Amazon EKS d’accéder aux nœuds d’un cluster. Lorsqu’elle est associée à une entrée d’accès avec portée Cluster, sa portée concerne l’ensemble du cluster, plutôt qu’un espace de noms unique. Cette stratégie est utilisée par les nœuds hybrides Amazon EKS.
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSHybridPolicy`
| Groupes d’API Kubernetes | Kubernetes Non-Resource URLs | Ressources Kubernetes | Verbes (autorisations) Kubernetes |
| --- | --- | --- | --- |
| `*` | | `nodes` | `list` |
## Amazon EKSCluster InsightsPolicy
**Note**
Cette politique s'applique uniquement aux rôles AWS liés aux services et ne peut pas être utilisée avec des rôles gérés par le client.
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSClusterInsightsPolicy`
Cette stratégie accorde des autorisations en lecture seule pour la fonctionnalité EKS Cluster Insights. La stratégie inclut les autorisations suivantes :
Accès aux nœuds : - Répertorier et afficher les nœuds du cluster - Lire les informations sur l’état des nœuds
DaemonSet Accès : - Accès en lecture à la configuration de kube-proxy
Cette stratégie est automatiquement gérée par le service EKS pour la fonctionnalité Cluster Insights. Pour de plus amples informations, veuillez consulter [Préparation aux mises à niveau des versions Kubernetes et résolution des erreurs de configuration grâce aux informations sur les clusters](cluster-insights.md).
## AWSBackupFullAccessPolicyForBackup
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AWSBackupFullAccessPolicyForBackup`
AWSBackupFullAccessPolicyForBackup
Cette politique accorde les autorisations nécessaires à AWS Backup pour gérer et créer des sauvegardes du cluster EKS. Cette politique inclut les autorisations suivantes :
| Groupes d’API Kubernetes | Ressources Kubernetes | Verbes (autorisations) Kubernetes |
| --- | --- | --- |
| `*` | `*` | `list`, `get` |
## AWSBackupFullAccessPolicyForRestore
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AWSBackupFullAccessPolicyForRestore`
AWSBackupFullAccessPolicyForRestore
Cette politique accorde les autorisations nécessaires à AWS Backup pour gérer et restaurer les sauvegardes du cluster EKS. Cette politique inclut les autorisations suivantes :
| Groupes d’API Kubernetes | Ressources Kubernetes | Verbes (autorisations) Kubernetes |
| --- | --- | --- |
| `*` | `*` | `list`, `get`, `create` |
## Amazon EKSACKPolicy
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSACKPolicy`
Cette politique accorde les autorisations nécessaires pour que les AWS Controllers for Kubernetes (ACK) puissent gérer les AWS ressources de Kubernetes. La stratégie inclut les autorisations suivantes :
Gestion personnalisée des ressources ACK :
+ Accès complet à toutes les ressources personnalisées du service ACK sur plus de 50 AWS services, notamment S3, RDS, DynamoDB, Lambda, EC2, etc.
+ Créez, lisez, mettez à jour et supprimez les définitions de ressources personnalisées ACK.
Accès à l'espace de noms :
+ Accès en lecture aux espaces de noms pour l'organisation des ressources.
Élection du chef :
+ Créez et lisez des baux de coordination pour l'élection des dirigeants.
+ Mettez à jour et supprimez les baux spécifiques des contrôleurs de service ACK.
Gestion des événements :
+ Créez et corrigez des événements pour les opérations ACK.
Cette politique est conçue pour prendre en charge la gestion complète AWS des ressources via Kubernetes APIs. Amazon EKS crée automatiquement une entrée d'accès avec cette politique d'accès pour le rôle IAM de fonctionnalité que vous fournissez lors de la création de la fonctionnalité ACK.
| Groupes d’API Kubernetes | Ressources Kubernetes | Verbes (autorisations) Kubernetes |
| --- | --- | --- |
| | `namespaces` | `get`, `watch`, `list` |
| `services.k8s.aws`, `acm.services.k8s.aws`, `acmpca.services.k8s.aws`, `apigateway.services.k8s.aws`, `apigatewayv2.services.k8s.aws`, `applicationautoscaling.services.k8s.aws`, `athena.services.k8s.aws`, `bedrock.services.k8s.aws`, `bedrockagent.services.k8s.aws`, `bedrockagentcorecontrol.services.k8s.aws`, `cloudfront.services.k8s.aws`, `cloudtrail.services.k8s.aws`, `cloudwatch.services.k8s.aws`, `cloudwatchlogs.services.k8s.aws`, `codeartifact.services.k8s.aws`, `cognitoidentityprovider.services.k8s.aws`, `documentdb.services.k8s.aws`, `dynamodb.services.k8s.aws`, `ec2.services.k8s.aws`, `ecr.services.k8s.aws`, `ecrpublic.services.k8s.aws`, `ecs.services.k8s.aws`, `efs.services.k8s.aws`, `eks.services.k8s.aws`, `elasticache.services.k8s.aws`, `elbv2.services.k8s.aws`, `emrcontainers.services.k8s.aws`, `eventbridge.services.k8s.aws`, `iam.services.k8s.aws`, `kafka.services.k8s.aws`, `keyspaces.services.k8s.aws`, `kinesis.services.k8s.aws`, `kms.services.k8s.aws`, `lambda.services.k8s.aws`, `memorydb.services.k8s.aws`, `mq.services.k8s.aws`, `networkfirewall.services.k8s.aws`, `opensearchservice.services.k8s.aws`, `organizations.services.k8s.aws`, `pipes.services.k8s.aws`, `prometheusservice.services.k8s.aws`, `ram.services.k8s.aws`, `rds.services.k8s.aws`, `recyclebin.services.k8s.aws`, `route53.services.k8s.aws`, `route53resolver.services.k8s.aws`, `s3.services.k8s.aws`, `s3control.services.k8s.aws`, `sagemaker.services.k8s.aws`, `secretsmanager.services.k8s.aws`, `ses.services.k8s.aws`, `sfn.services.k8s.aws`, `sns.services.k8s.aws`, `sqs.services.k8s.aws`, `ssm.services.k8s.aws`, `wafv2.services.k8s.aws` | `*` | `*` |
| `coordination.k8s.io` | `leases` | `create`, `get`, `list`, `watch` |
| `coordination.k8s.io` | `leases`(location de contrôleurs de service ACK spécifiques uniquement) | `delete`, `update`, `patch` |
| | `events` | `create`, `patch` |
| `apiextensions.k8s.io` | `customresourcedefinitions` | `*` |
## EKSArgoCDClusterPolitique d'Amazon
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSArgoCDClusterPolicy`
Cette politique accorde les autorisations nécessaires au niveau du cluster pour permettre à Argo CD de découvrir des ressources et de gérer les objets délimités au cluster. La stratégie inclut les autorisations suivantes :
Gestion de l'espace de noms :
+ Créez, lisez, mettez à jour et supprimez des espaces de noms pour la gestion des espaces de noms d'applications.
Gestion des définitions de ressources personnalisées :
+ Gérez les applications spécifiques à Argo CD CRDs (Applications, AppProjects, ApplicationSets).
Découverte d'API :
+ Accès en lecture aux points de terminaison de l'API Kubernetes pour la découverte des ressources.
Cette politique est conçue pour prendre en charge les opérations Argo CD au niveau du cluster, notamment la gestion des espaces de noms et l'installation du CRD. Amazon EKS crée automatiquement une entrée d'accès avec cette politique d'accès pour le rôle IAM de fonctionnalité que vous fournissez lors de la création de la fonctionnalité Argo CD.
| Groupes d’API Kubernetes | Kubernetes Non-Resource URLs | Ressources Kubernetes | Verbes (autorisations) Kubernetes |
| --- | --- | --- | --- |
| | | `namespaces` | `create`, `get`, `update`, `patch`, `delete` |
| `apiextensions.k8s.io` | | `customresourcedefinitions` | `create` |
| `apiextensions.k8s.io` | | `customresourcedefinitions`(Argo CD CRDs uniquement) | `get`, `update`, `patch`, `delete` |
| | `/api`, `/api/*`, `/apis`, `/apis/*` | | `get` |
## Amazon EKSArgo CDPolicy
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSArgoCDPolicy`
Cette politique accorde les autorisations au niveau de l'espace de noms nécessaires pour que l'Argo CD puisse déployer et gérer des applications. La stratégie inclut les autorisations suivantes :
Gestion des secrets :
+ Accès complet aux secrets relatifs aux informations d'identification Git et aux secrets du cluster.
ConfigMap Accès :
+ Accès en lecture ConfigMaps à pour envoyer des avertissements si les clients essaient d'utiliser un Argo CD non compatible. ConfigMaps
Gestion des événements :
+ Lisez et créez des événements pour le suivi du cycle de vie des applications.
Gestion des ressources Argo CD :
+ Accès complet aux applications ApplicationSets, et AppProjects.
+ Gérez les finaliseurs et le statut des ressources Argo CD.
Cette politique est conçue pour prendre en charge les opérations Argo CD au niveau de l'espace de noms, y compris le déploiement et la gestion des applications. Amazon EKS crée automatiquement une entrée d'accès avec cette politique d'accès pour le rôle IAM de fonctionnalité que vous fournissez lors de la création de la fonctionnalité Argo CD, dans le cadre de l'espace de noms Argo CD.
| Groupes d’API Kubernetes | Ressources Kubernetes | Verbes (autorisations) Kubernetes |
| --- | --- | --- |
| | `secrets` | `*` |
| | `configmaps` | `get`, `list`, `watch` |
| | `events` | `get`, `list`, `watch`, `patch`, `create` |
| `argoproj.io` | `applications`, `applications/finalizers`, `applications/status`, `applicationsets`, `applicationsets/finalizers`, `applicationsets/status`, `appprojects`, `appprojects/finalizers`, `appprojects/status` | `*` |
## Amazon EKSKROPolicy
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSKROPolicy`
Cette politique accorde les autorisations nécessaires à la capacité kro (Kube Resource Orchestrator) de créer et de gérer des Kubernetes personnalisés. APIs La stratégie inclut les autorisations suivantes :
Gestion des ressources kro :
+ Accès complet à toutes les ressources Kro, y compris ResourceGraphDefinitions les instances de ressources personnalisées.
Gestion des définitions de ressources personnalisées :
+ Créez, lisez, mettez à jour et supprimez CRDs pour les options personnalisées APIs définies par ResourceGraphDefinitions.
Élection du chef :
+ Créez et lisez des baux de coordination pour l'élection des dirigeants.
+ Mettez à jour et supprimez le bail du contrôleur Kro.
Gestion des événements :
+ Créez et corrigez des événements pour les opérations Kro.
Cette politique est conçue pour prendre en charge la composition complète des ressources et la gestion personnalisée des API via kro. Amazon EKS crée automatiquement une entrée d'accès avec cette politique d'accès pour le rôle IAM de fonctionnalité que vous fournissez lors de la création de la fonctionnalité kro.
| Groupes d’API Kubernetes | Ressources Kubernetes | Verbes (autorisations) Kubernetes |
| --- | --- | --- |
| `kro.run` | `*` | `*` |
| `apiextensions.k8s.io` | `customresourcedefinitions` | `*` |
| `coordination.k8s.io` | `leases` | `create`, `get`, `list`, `watch` |
| `coordination.k8s.io` | `leases`(location de manette Kro uniquement) | `delete`, `update`, `patch` |
| | `events` | `create`, `patch` |
## Mises à jour des stratégies d'accès
Affichez les détails sur les mises à jour des stratégies d'accès depuis leur introduction. Pour recevoir des alertes automatiques concernant les modifications apportées à cette page, abonnez-vous au flux RSS de la page [Historique du document](doc-history.md).
| Modifier | Description | Date |
| --- | --- | --- |
| Ajouter des politiques pour les fonctionnalités EKS | Publier`AmazonEKSACKPolicy`, `AmazonEKSArgoCDClusterPolicy``AmazonEKSArgoCDPolicy`, et `AmazonEKSKROPolicy` pour gérer les fonctionnalités d'EKS | 22 novembre 2025 |
| Addition `AmazonEKSSecretReaderPolicy` | Ajouter une nouvelle politique pour l'accès en lecture seule aux secrets | 6 novembre 2025 |
| Ajout de la stratégie pour EKS Cluster Insights | Publication `AmazonEKSClusterInsightsPolicy` | 2 décembre 2024 |
| Ajout des stratégies pour Amazon EKS Hybrid | Publication `AmazonEKSHybridPolicy` | 2 décembre 2024 |
| Ajout des stratégies pour le mode automatique Amazon EKS | Ces politiques d'accès autorisent le rôle IAM du cluster et le rôle IAM du nœud à appeler Kubernetes. APIs AWS les utilise pour automatiser les tâches de routine relatives aux ressources de stockage, de calcul et de réseau. | 2 décembre 2024 |
| Addition `AmazonEKSAdminViewPolicy` | Ajout d’une nouvelle stratégie pour étendre les autorisations de visualisation, incluant l’accès à des ressources comme Secrets. | 23 avril 2024 |
| Stratégies d'accès introduites. | Amazon EKS a introduit des stratégies d'accès. | 29 mai 2023 |
# Modifier le mode d’authentification pour utiliser les entrées d’accès
Pour commencer à utiliser les entrées d'accès, vous devez remplacer le mode d'authentification du cluster par les modes `API_AND_CONFIG_MAP` ou `API`. Cela ajoute l'API pour les entrées d'accès.
## Console AWS
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Choisissez le nom du cluster pour lequel vous souhaitez créer une entrée d'accès.
1. Choisissez l'onglet **Access**.
1. Le **Mode d’authentification** indique le mode d’authentification actuel du cluster. Si le mode indique API EKS, vous pouvez déjà ajouter des entrées d’accès et ignorer les étapes restantes.
1. Choisissez **Gérer l'accès**.
1. Pour le **Mode d’authentification du cluster**, sélectionnez un mode avec l’API EKS. Veuillez noter que vous ne pouvez pas revenir à un mode qui supprime l’API EKS et les entrées d’accès.
1. Sélectionnez **Enregistrer les modifications**. Amazon EKS commence à mettre à jour le cluster, le statut du cluster passe à Mise à jour en cours et la modification est enregistrée dans l’onglet **Historique des mises à jour**.
1. Veuillez patienter jusqu’à ce que le statut du cluster revienne à « Actif ». Lorsque le cluster est actif, vous pouvez suivre les étapes décrites dans [Créer des entrées d’accès](creating-access-entries.md) pour ajouter un accès au cluster pour les principaux IAM.
## AWS CLI
1. Installez l’AWS CLI, comme indiqué dans la section [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) du *Guide de l’utilisateur de l’interface de la ligne de commande AWS*.
1. Exécutez la commande suivante. Remplacez *my-cluster* par le nom de votre cluster. Si vous souhaitez désactiver définitivement la méthode `ConfigMap`, remplacez `API_AND_CONFIG_MAP` par `API`.
Amazon EKS commence à mettre à jour le cluster, le statut du cluster passe à MISE À JOUR EN COURS et la modification est enregistrée dans la liste **aws eks list-updates**.
```
aws eks update-cluster-config --name my-cluster --access-config authenticationMode=API_AND_CONFIG_MAP
```
1. Veuillez patienter jusqu’à ce que le statut du cluster revienne à « Actif ». Lorsque le cluster est actif, vous pouvez suivre les étapes décrites dans [Créer des entrées d’accès](creating-access-entries.md) pour ajouter un accès au cluster pour les principaux IAM.
## Version de plateforme requise
Pour utiliser les *entrées d’accès*, le cluster doit disposer d’une version de plateforme identique ou supérieure à celle indiquée dans le tableau suivant, ou d’une version de Kubernetes supérieure à celles indiquées dans le tableau. Si votre version de Kubernetes ne figure pas dans le tableau, toutes les versions de la plateforme prennent en charge les entrées d’accès.
| Version de Kubernetes | Version de la plateforme |
| --- | --- |
| Non répertoriée | Tous pris en charge |
| `1.30` | `eks.2` |
| `1.29` | `eks.1` |
| `1.28` | `eks.6` |
Pour plus d’informations, consultez [platform-versions](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html).
# Créer des entrées d’accès
Avant de créer des entrées d'accès, tenez compte des éléments suivants :
+ Un mode d’authentification correctement configuré. Consultez [Modifier le mode d’authentification pour utiliser les entrées d’accès](setting-up-access-entries.md).
+ Une *entrée d'accès* inclut l'Amazon Resource Name (ARN) d'un et d'un seul principal IAM existant. Un principal IAM ne peut pas être inclus dans plus d’une entrée d’accès. Considérations supplémentaires concernant l'ARN que vous spécifiez :
+ Les bonnes pratiques IAM recommandent d'accéder à votre cluster en utilisant des *rôles* IAM dotés d'informations d'identification à court terme, plutôt que des *utilisateurs* IAM dotés d'informations d'identification à long terme. Pour plus d’informations, consultez [Exiger que les utilisateurs humains utilisent la fédération avec un fournisseur d’identité pour accéder à AWS à l’aide d’informations d’identification temporaires](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) dans le *Guide d’utilisateur IAM*.
+ Si l'ARN est destiné à un rôle IAM, il *peut* inclure un chemin. Les ARN dans les entrées `aws-auth` `ConfigMap` *ne peuvent pas* inclure de chemin. Par exemple, votre ARN peut être ` arn:aws:iam::<111122223333>:role/` ou` arn:aws:iam::<111122223333>:role/`.
+ Si le type de l’entrée d’accès est différent de `STANDARD` (voir la considération suivante concernant les types), l’ARN doit appartenir au même compte AWS que celui du cluster. Si le type est `STANDARD`, l’ARN peut appartenir soit au même compte AWS, soit à un autre compte que celui du cluster.
+ Vous ne pouvez pas modifier le principal IAM après la création de l’entrée d’accès.
+ Si vous supprimez le principal IAM correspondant à cet ARN, l’entrée d’accès n’est pas supprimée automatiquement. Nous vous recommandons de supprimer l'entrée d'accès avec un ARN pour un principal IAM que vous supprimez. Si vous ne supprimez pas l’entrée d’accès et que vous recréez plus tard le principal IAM, même avec le même ARN, l’entrée d’accès ne fonctionnera pas. Cela s’explique par le fait que, bien que l’ARN soit identique pour le principal IAM recréé, le `roleID` ou le `userID` (consultable avec la commande AWS CLI `aws sts get-caller-identity`) du principal IAM recréé est différent de celui du principal IAM d’origine. Même si le `roleID` ou le `userID` du principal IAM ne s’affiche pas dans l’entrée d’accès, Amazon EKS le conserve en interne avec l’entrée d’accès.
+ Chaque entrée d’accès possède un *type*. Le type de l’entrée d’accès dépend du type de ressource associée ; il ne définit pas les autorisations. Si vous ne spécifiez pas de type, Amazon EKS définit automatiquement le type sur `STANDARD`
+ `EC2_LINUX` : pour un rôle IAM utilisé avec des nœuds autogérés Linux ou Bottlerocket
+ `EC2_WINDOWS` : pour un rôle IAM utilisé avec des nœuds autogérés Windows
+ `FARGATE_LINUX` : pour un rôle IAM utilisé avec AWS Fargate (Fargate)
+ `HYBRID_LINUX` : pour un rôle IAM utilisé avec des nœuds hybrides
+ `STANDARD` : type par défaut si aucun n’est spécifié
+ `EC2` : pour les classes de nœuds personnalisées du mode automatique EKS. Pour de plus amples informations, consultez [Création d’une entrée d’accès pour la classe de nœuds](create-node-class.md#auto-node-access-entry).
+ Vous ne pouvez pas modifier le type après la création de l’entrée d’accès.
+ Il n’est pas nécessaire de créer une entrée d’accès pour un rôle IAM utilisé par un groupe de nœuds géré ou par un profil Fargate. EKS créera des entrées d’accès (si cette option est activée) ou mettra à jour la ConfigMap d’authentification (si les entrées d’accès ne sont pas disponibles)
+ Si le type d'entrée d'accès est `STANDARD`, vous pouvez spécifier un *nom d'utilisateur* pour l'entrée d'accès. Si vous ne spécifiez aucune valeur pour le nom d’utilisateur, Amazon EKS en attribue automatiquement une, selon le type d’entrée d’accès et selon que le principal IAM indiqué est un rôle IAM ou un utilisateur IAM. Sauf si vous avez une raison précise de définir votre propre nom d’utilisateur, il est recommandé de ne pas en spécifier et de laisser Amazon EKS le générer automatiquement. Si vous spécifiez votre propre nom d'utilisateur :
+ Il ne peut pas commencer par `system:`, `eks:`, `aws:`, `amazon:` ou `iam:`.
+ Si le nom d’utilisateur s’applique à un rôle IAM, il est recommandé d’ajouter `{{SessionName}}` ou `{{SessionNameRaw}}` à la fin de votre nom d’utilisateur. Si vous ajoutez `{{SessionName}}` ou `{{SessionNameRaw}}` à votre nom d’utilisateur, alors le nom d’utilisateur doit comporter un deux-points *avant* \$1\$1SessionName\$1\$1. Lorsque ce rôle est assumé, le nom de la session AWS STS utilisé au moment de l’assumer est automatiquement transmis au cluster et apparaîtra dans les journaux CloudTrail. Par exemple, vous ne pouvez pas avoir le nom d’utilisateur `john{{SessionName}}`. Le nom d'utilisateur doit être `:john{{SessionName}}` ou `jo:hn{{SessionName}}`. Il suffit que les deux-points soient devant `{{SessionName}}`. Le nom d'utilisateur généré par Amazon EKS dans le tableau suivant inclut un ARN. Comme un ARN inclut les deux-points, il répond à cette exigence. Le deux-points n’est pas requis si vous n’incluez pas `{{SessionName}}` dans votre nom d’utilisateur. Notez que dans `{{SessionName}}`, le caractère spécial « @ » est remplacé par « - » dans le nom de session. `{{SessionNameRaw}}` conserve les caractères spéciaux dans le nom de session.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/creating-access-entries.html)
Vous ne pouvez pas modifier le nom d'utilisateur une fois l'entrée d'accès créée.
+ Si le type de l’entrée d’accès est `STANDARD` et que vous souhaitez utiliser l’autorisation Kubernetes RBAC, vous pouvez ajouter un ou plusieurs *noms de groupes* à l’entrée d’accès. Après avoir créé une entrée d'accès, vous pouvez ajouter et supprimer des noms de groupes. Pour permettre au principal IAM d’accéder aux objets Kubernetes de votre cluster, vous devez créer et gérer les ressources d’autorisation Kubernetes basées sur les rôles (RBAC). Créez des objets Kubernetes `RoleBinding` ou `ClusterRoleBinding` sur votre cluster qui spécifient le nom du groupe sous forme de `subject` pour `kind: Group`. Kubernetes autorise le principal IAM à accéder aux objets du cluster uniquement si ceux-ci sont définis dans un objet `Role` ou `ClusterRole`, et si ce rôle est spécifié dans l’objet `roleRef` de votre liaison. Si vous spécifiez des noms de groupe, il est recommandé de bien maîtriser objets d’autorisation basée sur les rôles (RBAC) . Pour plus d'informations, consultez [Utilisation de l'autorisation RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) dans la documentation Kubernetes.
**Important**
Amazon EKS ne vérifie pas si des objets RBAC Kubernetes existants dans votre cluster incluent les noms de groupes que vous spécifiez. Par exemple, si vous créez une entrée d’accès pour un groupe qui n’existe pas encore, EKS créera ce groupe au lieu de renvoyer une erreur.
Au lieu ou en complément de l’autorisation Kubernetes pour permettre au principal IAM d’accéder aux objets Kubernetes de votre cluster, vous pouvez associer des *stratégies d’accès* Amazon EKS à une entrée d’accès. Amazon EKS autorise le principal IAM à accéder aux objets Kubernetes du cluster en fonction des autorisations définies dans la stratégie d’accès. Vous pouvez limiter la portée d’une stratégie d’accès à certains espaces de noms Kubernetes que vous spécifiez. L’utilisation de stratégies d’accès ne nécessite pas de gérer des objets RBAC Kubernetes. Pour de plus amples informations, consultez [Association des stratégies d’accès aux entrées d’accès](access-policies.md).
+ Si vous créez une entrée d'accès avec le type `EC2_LINUX` ou `EC2_Windows`, le principal IAM qui crée l'entrée d'accès doit avoir l'autorisation `iam:PassRole`. Pour plus d’informations, consultez la section [Octroi d’autorisations à un utilisateur pour transférer un rôle à un service AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html) dans le *IAM Guide de l’utilisateur*.
+ À l'instar du [comportement IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency) standard, la création et les mises à jour des entrées d'accès sont finalement cohérentes et prennent effet au bout de plusieurs secondes après que l'appel API initial a été renvoyé avec succès. Vous devez concevoir vos applications de sorte qu'elles tiennent compte de ces retards potentiels. Nous recommandons de ne pas inclure la création ou la mise à jour d’entrées d’accès dans les parcours applicatifs critiques ou nécessitant une haute disponibilité. Au lieu de cela, procédez aux modifications dans une routine d'initialisation ou d'installation distincte que vous exécutez moins souvent. Veillez également à vérifier que les modifications ont été propagées avant que les processus de production en dépendent.
+ Les entrées d’accès ne prennent pas en charge les [rôles liés aux services](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html). Vous ne pouvez pas créer d’entrée d’accès lorsque l’ARN du principal correspond à un rôle lié à un service. Vous pouvez identifier les rôles liés aux services par leur ARN, qui est au format ` arn:aws:iam::*:role/aws-service-role/*`.
Vous pouvez créer une entrée d’accès à l’aide de la AWS Management Console ou de la CLI AWS.
## AWS Management Console
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Choisissez le nom du cluster pour lequel vous souhaitez créer une entrée d'accès.
1. Choisissez l'onglet **Access**.
1. Choisissez **Créer une entrée d'accès**.
1. Pour le **principal IAM**, sélectionnez un utilisateur ou un rôle IAM existant. Les bonnes pratiques IAM recommandent d'accéder à votre cluster en utilisant des *rôles* IAM dotés d'informations d'identification à court terme, plutôt que des *utilisateurs* IAM dotés d'informations d'identification à long terme. Pour plus d’informations, consultez [Exiger que les utilisateurs humains utilisent la fédération avec un fournisseur d’identité pour accéder à AWS à l’aide d’informations d’identification temporaires](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) dans le *Guide d’utilisateur IAM*.
1. **Pour **Type**, si l'entrée d'accès concerne le rôle de nœud utilisé pour les nœuds Amazon EC2 autogérés, sélectionnez **EC2 Linux** ou EC2 Windows.** Dans le cas contraire, acceptez le type par défaut (**Standard**).
1. Si le **type** que vous avez choisi est **Standard** et que vous souhaitez spécifier un **nom d'utilisateur**, saisissez-le.
1. Si le **Type** que vous avez sélectionné **Standard** et que vous souhaitez utiliser l’autorisation Kubernetes basée sur RBAC pour le principal IAM, spécifiez un ou plusieurs noms dans le champ **Groupes**. Si vous ne spécifiez aucun groupe et que vous préférez utiliser l’autorisation Amazon EKS, vous pourrez associer une stratégie d’accès à une étape ultérieure ou après la création de l’entrée d’accès.
1. (Facultatif) Pour **Balises**, attribuez des étiquettes à l'entrée d'accès. Par exemple, pour faciliter la recherche de toutes les ressources portant la même balise.
1. Choisissez **Suivant**.
1. Sur la page **Ajouter une stratégie d’accès**, si le type que vous avez sélectionné était **Standard** et que vous souhaitez qu’Amazon EKS autorise le principal IAM à accéder aux objets Kubernetes du cluster, suivez les étapes ci-dessous. Sinon, choisissez **Next (Suivant)**.
1. Pour **Nom de la politique**, choisissez une stratégie d'accès. Vous ne pouvez pas consulter les autorisations des stratégies d’accès, mais celles-ci incluent des autorisations similaires à celles des objets `ClusterRole` destinés aux utilisateurs Kubernetes. Pour plus d’informations, consultez la section [Rôles destinés aux utilisateurs](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) dans la documentation Kubernetes.
1. Choisissez l’une des options suivantes :
+ **Cluster** : sélectionnez cette option si vous souhaitez qu’Amazon EKS autorise le principal IAM à disposer des autorisations définies dans la stratégie d’accès pour l’ensemble des objets Kubernetes du cluster.
+ **Espace de noms Kubernetes** : sélectionnez cette option si vous souhaitez qu’Amazon EKS autorise le principal IAM à disposer des autorisations définies dans la stratégie d’accès, mais uniquement pour les objets Kubernetes d’un espace de noms spécifique du cluster. Dans le champ **Espace de noms**, saisissez le nom de l’espace de noms Kubernetes présent sur votre cluster. Si vous souhaitez ajouter des espaces de noms supplémentaires, choisissez **Ajouter un nouvel espace de noms** et entrez son nom.
1. Pour ajouter des politiques supplémentaires, Sélectionnez **Ajouter une politique**. Vous pouvez définir la portée de chaque politique différemment, mais vous ne pouvez ajouter chaque politique qu'une seule fois.
1. Choisissez **Suivant**.
1. Vérifiez la configuration de votre entrée d'accès. Si quelque chose semble incorrect, choisissez **Précédent** pour revenir en arrière et corriger l'erreur. Si la configuration est correcte, choisissez **Créer**.
## AWS CLI
1. Installez l’AWS CLI, comme indiqué dans la section [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) du Guide de l’utilisateur de l’interface de la ligne de commande AWS.
1. Vous pouvez utiliser n’importe lequel des exemples ci-dessous pour créer des entrées d’accès :
+ Créez une entrée d'accès pour un groupe de nœuds Linux Amazon EC2 autogéré. Remplacez *my-cluster* par le nom de votre cluster, *111122223333* par votre ID de compte AWS, et *EKS-my-cluster-self-managed-ng-1* par le nom de votre [rôle IAM de nœud](create-node-role.md). Si votre groupe de nœuds est un groupe de nœuds Windows, remplacez *EC2\$1LINUX* par `EC2_Windows`.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/EKS-my-cluster-self-managed-ng-1 --type EC2_LINUX
```
Vous ne pouvez pas utiliser l’option `--kubernetes-groups` lorsque vous spécifiez un type autre que `STANDARD`. Vous ne pouvez pas associer de stratégie d’accès à cette entrée d’accès, car son type est une valeur autre que `STANDARD`.
+ Créez une entrée d’accès permettant à un rôle IAM qui n’est pas utilisé pour un groupe de nœuds autogéré Amazon EC2 d’être autorisé par Kubernetes à accéder à votre cluster. Remplacez *my-cluster* par le nom de votre cluster, *111122223333* par votre ID de compte AWS, et *my-role* par le nom de votre rôle IAM. Remplacez *Utilisateurs* par le nom d’un groupe que vous avez défini dans un objet Kubernetes `RoleBinding` ou `ClusterRoleBinding` de votre cluster.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role --type STANDARD --user Viewers --kubernetes-groups Viewers
```
+ Créez une entrée d'accès qui permet à un utilisateur IAM de s'authentifier auprès de votre cluster. Cet exemple est fourni car c'est possible, bien que les bonnes pratiques IAM recommandent d'accéder à votre cluster en utilisant des *rôles* IAM dotés d'informations d'identification à court terme, plutôt que des *utilisateurs* IAM dotés d'informations d'identification à long terme. Pour plus d’informations, consultez [Exiger que les utilisateurs humains utilisent la fédération avec un fournisseur d’identité pour accéder à AWS à l’aide d’informations d’identification temporaires](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) dans le *Guide d’utilisateur IAM*.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:user/my-user --type STANDARD --username my-user
```
Si vous souhaitez que cet utilisateur ait davantage d’accès au cluster que les autorisations fournies par les rôles de découverte de l’API Kubernetes, vous devez associer une stratégie d’accès à l’entrée d’accès, puisque l’option `--kubernetes-groups` n’est pas utilisée. Pour plus d’informations, consultez [Association des stratégies d’accès aux entrées d’accès](access-policies.md) et [Rôles de découverte d’API](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#discovery-roles) dans la documentation Kubernetes.
# Mettre à jour les entrées d’accès
Vous pouvez mettre à jour une entrée d’accès à l’aide de la AWS Management Console ou de l’AWS CLI.
## AWS Management Console
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Choisissez le nom du cluster pour lequel vous souhaitez créer une entrée d'accès.
1. Choisissez l'onglet **Access**.
1. Choisissez l'entrée d'accès que vous voulez mettre à jour.
1. Choisissez **Modifier**.
1. Pour **Nom d'utilisateur**, vous pouvez modifier la valeur existante.
1. Pour **Groupes**, vous pouvez supprimer les noms de groupes existants ou en ajouter de nouveaux. Si les noms de groupes suivants existent, veuillez ne pas les supprimer : **system:nodes** ou **system:bootstrappers**. La suppression de ces groupes peut entraîner un dysfonctionnement de votre cluster. Si vous ne spécifiez aucun nom de groupe et que vous voulez utiliser l’autorisation Amazon EKS, associez une [stratégie d’accès](access-policies.md) dans une étape ultérieure.
1. Pour **Balises**, vous pouvez attribuer des étiquettes à l'entrée d'accès. Par exemple, pour faciliter la recherche de toutes les ressources portant la même balise. Vous pouvez également supprimer des balises existantes.
1. Sélectionnez **Enregistrer les modifications**.
1. Si vous souhaitez associer une stratégie d'accès à l'entrée, consultez [Association des stratégies d’accès aux entrées d’accès](access-policies.md).
## AWS CLI
1. Installez l’AWS CLI, comme indiqué dans la section [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) du Guide de l’utilisateur de l’interface de la ligne de commande AWS.
1. Pour mettre à jour une entrée d’accès, remplacez *my-cluster* par le nom de votre cluster, *111122223333* par votre ID de compte AWS et *EKS-my-cluster-my-namespace-Viewers* par le nom d’un rôle IAM.
```
aws eks update-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers --kubernetes-groups Viewers
```
Vous ne pouvez pas utiliser l’option `--kubernetes-groups` si le type de l’entrée d’accès est une valeur autre que `STANDARD`. Vous ne pouvez pas non plus associer une stratégie d’accès à une entrée d’accès dont le type est autre que `STANDARD`.
# Supprimer les entrées d’accès
Si vous découvrez que vous avez supprimé une entrée d'accès par erreur, vous pouvez toujours la recréer. Si l’entrée d’accès que vous supprimez est associée à des stratégies d’accès, les associations sont automatiquement supprimées. Il n’est pas nécessaire de dissocier les stratégies d’accès d’une entrée d’accès avant de supprimer cette entrée d’accès.
Vous pouvez supprimer une entrée d’accès à l’aide de la AWS Management Console ou de la CLI AWS.
## AWS Management Console
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Choisissez le nom du cluster dont vous souhaitez supprimer une entrée d'accès.
1. Choisissez l'onglet **Access**.
1. Dans la liste des **entrées d'accès**, choisissez l'entrée d'accès que vous souhaitez supprimer.
1. Sélectionnez Delete.
1. Dans la boîte de dialogue de confirmation, choisissez **Delete** (Supprimer).
## AWS CLI
1. Installez l’AWS CLI, comme indiqué dans la section [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) du Guide de l’utilisateur de l’interface de la ligne de commande AWS.
1. Pour supprimer une entrée d’accès Remplacez *my-cluster* par le nom de votre cluster, *111122223333* par votre ID de compte AWS et *my-role* par le nom du rôle IAM auquel vous ne souhaitez plus donner accès à votre cluster.
```
aws eks delete-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role
```
# Définir un nom d’utilisateur personnalisé pour les entrées d’accès Amazon EKS
Lors de la création d’entrées d’accès pour Amazon EKS, vous pouvez soit utiliser le nom d’utilisateur généré automatiquement, soit spécifier un nom d’utilisateur personnalisé. Cette page explique les deux options et vous guide dans la configuration d’un nom d’utilisateur personnalisé.
## Présentation de
Le nom d’utilisateur dans une entrée d’accès est utilisé pour identifier le principal IAM dans les journaux et les pistes d’audit Kubernetes. Par défaut, Amazon EKS génère un nom d’utilisateur basé sur l’ARN de l’identité IAM, mais vous pouvez spécifier un nom d’utilisateur personnalisé si nécessaire.
## Génération du nom d’utilisateur par défaut
Si vous ne spécifiez pas de valeur pour le nom d’utilisateur, Amazon EKS génère automatiquement un nom d’utilisateur basé sur l’identité IAM :
+ **Pour les utilisateurs IAM** :
+ EKS définit le nom d’utilisateur Kubernetes sur l’ARN de l’utilisateur IAM
+ Exemple :
```
{arn-aws}iam::<111122223333>:user/
```
+ **Pour les rôles IAM** :
+ EKS définit le nom d’utilisateur Kubernetes en fonction de l’ARN du rôle IAM
+ L’ARN STS du rôle lorsqu’il est assumé. Amazon EKS ajoute `{{SessionName}}` au rôle. Si l'ARN du rôle que vous avez spécifié contenait un chemin, Amazon EKS le supprime dans le nom d'utilisateur généré.
+ Exemple :
```
{arn-aws}sts::<111122223333>:assumed-role//{{SessionName}}
```
À moins que vous n’ayez une raison particulière de spécifier votre propre nom d’utilisateur, nous vous recommandons de ne pas en spécifier et de laisser Amazon EKS le générer automatiquement pour vous.
## Définition d’un nom d’utilisateur personnalisé
Lors de la création d’une entrée d’accès, vous pouvez spécifier un nom d’utilisateur personnalisé à l’aide du paramètre `--username` :
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD --username
```
### Exigences relatives aux noms d’utilisateur personnalisés
Si vous spécifiez un nom d’utilisateur personnalisé :
+ Le nom d’utilisateur ne peut pas commencer par `system:`, `eks:`, `aws:`, `amazon:` ou `iam:`.
+ Si le nom d’utilisateur s’applique à un rôle IAM, il est recommandé d’ajouter `{{SessionName}}` ou `{{SessionNameRaw}}` à la fin de votre nom d’utilisateur.
+ Si vous ajoutez l'un `{{SessionName}}` ou `{{SessionNameRaw}}` l'autre à votre nom d'utilisateur, celui-ci doit inclure deux points *avant* \$1\$1SessionName\$1\$1.
# Création d’une entrée d’accès pour un rôle ou un utilisateur IAM à l’aide d’une stratégie d’accès et de la CLI AWS
Créez des entrées d’accès Amazon EKS qui utilisent des stratégies d’accès EKS gérées par AWS afin d’accorder aux identités IAM des autorisations standardisées pour accéder aux clusters Kubernetes et les gérer.
## Présentation
Les entrées d’accès dans Amazon EKS définissent la manière dont les identités IAM (utilisateurs et rôles) peuvent accéder à vos clusters Kubernetes et interagir avec eux. En créant des entrées d’accès avec des stratégies d’accès EKS, vous pouvez :
+ Accorder à des utilisateurs ou rôles IAM spécifiques l’accès à votre cluster EKS
+ Contrôler les autorisations à l’aide des stratégies d’accès EKS gérées par AWS, qui offrent des ensembles d’autorisations standardisés prédéfinis
+ Limiter les autorisations à des espaces de noms spécifiques ou à l’échelle du cluster
+ Simplifier la gestion des accès sans modifier le ConfigMap `aws-auth` ni créer de ressources RBAC Kubernetes
+ Utiliser une méthode d’accès à Kubernetes intégrée à AWS, couvrant les cas d’utilisation courants tout en respectant les bonnes pratiques de sécurité
Cette méthode est recommandée pour la plupart des cas d’utilisation, car elle fournit des autorisations standardisées gérées par AWS, sans nécessiter de configuration manuelle de RBAC Kubernetes. Les stratégies d’accès EKS éliminent la nécessité de configurer manuellement les ressources RBAC Kubernetes et offrent des ensembles d’autorisations prédéfinis couvrant les cas d’utilisation les plus fréquents.
## Prérequis
+ Le *mode d’authentification* de votre cluster doit être configuré pour autoriser les *entrées d’accès*. Pour de plus amples informations, consultez [Modifier le mode d’authentification pour utiliser les entrées d’accès](setting-up-access-entries.md).
+ Installez l’AWS CLI, comme indiqué dans la section [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) du Guide de l’utilisateur de l’interface de la ligne de commande AWS.
## Étape 1 : définir l’entrée d’accès
1. Trouvez l’ARN de l’identité IAM (utilisateur ou rôle) à laquelle vous souhaitez accorder des autorisations.
+ Chaque identité IAM ne peut avoir qu’une seule entrée d’accès EKS.
1. Déterminez si vous souhaitez que les autorisations de la stratégie d’accès Amazon EKS s’appliquent uniquement à un espace de noms Kubernetes spécifique ou à l’ensemble du cluster.
+ Si vous souhaitez limiter les autorisations à un espace de noms spécifique, notez le nom de l’espace de noms.
1. Sélectionnez la stratégie d’accès EKS que vous souhaitez appliquer à l’identité IAM. Cette stratégie accorde des autorisations à l’intérieur du cluster. Notez l’ARN de la stratégie.
+ Pour obtenir la liste des stratégie, consultez les [stratégies d’accès disponibles](access-policy-permissions.md).
1. Déterminez si le nom d’utilisateur généré automatiquement convient à l’entrée d’accès ou si vous devez spécifier manuellement un nom d’utilisateur.
+ AWS génère automatiquement cette valeur en fonction de l’identité IAM. Vous pouvez définir un nom d’utilisateur personnalisé. Cela est visible dans les journaux Kubernetes.
+ Pour de plus amples informations, consultez [Définir un nom d’utilisateur personnalisé pour les entrées d’accès Amazon EKS](set-custom-username.md).
## Étape 2 : créer une entrée d’accès
Une fois l’entrée d’accès planifiée, utilisez la CLI AWS pour la créer.
L’exemple ci-dessous couvre la majorité des cas d’utilisation. [Affichez la référence de la CLI pour toutes les options de configuration](https://docs.aws.amazon.com/cli/latest/reference/eks/create-access-entry.html).
Vous attacherez la stratégie d’accès à l’étape suivante.
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD
```
## Étape 3 : attacher la stratégie d’accès
La commande varie selon que vous souhaitiez ou non limiter la stratégie d’accès à un espace de noms Kubernetes.
Vous aurez besoin de l’ARN de la stratégie d’accès. Consultez les [stratégies d’accès disponibles](access-policy-permissions.md).
### Création d’une stratégie sans limitation de la portée à un espace de noms
```
aws eks associate-access-policy --cluster-name --principal-arn --policy-arn
```
### Création d’une stratégie avec limitation de la portée à un espace de noms
```
aws eks associate-access-policy --cluster-name --principal-arn \
--access-scope type=namespace,namespaces=my-namespace1,my-namespace2 --policy-arn
```
## Étapes suivantes
+ [Création d’un fichier kubeconfig pour utiliser kubectl avec une identité IAM](create-kubeconfig.md)
# Création d’une entrée d’accès à l’aide des groupes Kubernetes avec la CLI AWS
Créer des entrées d’accès Amazon EKS qui utilisent les groupes Kubernetes pour l’autorisation et nécessitent une configuration RBAC manuelle.
**Note**
Dans la plupart des cas d’utilisation, nous recommandons d’utiliser les stratégies d’accès EKS plutôt que la méthode basée sur les groupes Kubernetes décrite dans cette page. Les stratégies d’accès EKS offrent une méthode plus simple et mieux intégrée à AWS pour gérer l’accès sans nécessiter de configuration RBAC manuelle. Utilisez l’approche basée sur les groupes Kubernetes uniquement lorsque vous avez besoin d’un contrôle plus granulaire que celui offert par les stratégies d’accès EKS.
## Présentation
Les entrées d’accès définissent la manière dont les identités IAM (utilisateurs et rôles) accèdent à vos clusters Kubernetes. L’approche basée sur les groupes Kubernetes accorde aux utilisateurs ou rôles IAM l’autorisation d’accéder à votre cluster EKS via les groupes RBAC standard de Kubernetes. Cette méthode implique la création et la gestion des ressources RBAC Kubernetes (Roles, RoleBindings, ClusterRoles et ClusterRoleBindings) et est recommandée lorsque vous avez besoin d’ensembles d’autorisations très personnalisés, d’exigences d’autorisation complexes ou que vous souhaitez maintenir des modèles de contrôle d’accès cohérents dans des environnements Kubernetes hybrides.
Cette rubrique ne couvre pas la création d’entrées d’accès pour les identités IAM utilisées par les instances Amazon EC2 afin de rejoindre les clusters EKS.
## Prérequis
+ Le *mode d’authentification* de votre cluster doit être configuré pour autoriser les *entrées d’accès*. Pour de plus amples informations, consultez [Modifier le mode d’authentification pour utiliser les entrées d’accès](setting-up-access-entries.md).
+ Installez l’AWS CLI, comme indiqué dans la section [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) du Guide de l’utilisateur de l’interface de la ligne de commande AWS.
+ Une bonne connaissance de la configuration RBAC Kubernetes est recommandée. Pour plus d'informations, consultez [Utilisation de l'autorisation RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) dans la documentation Kubernetes.
## Étape 1 : définir l’entrée d’accès
1. Recherchez l’ARN de l’identité IAM, comme un utilisateur ou un rôle, à laquelle vous souhaitez accorder des autorisations.
+ Chaque identité IAM ne peut avoir qu’une seule entrée d’accès EKS.
1. Déterminez les groupes Kubernetes que vous souhaitez associer à cette identité IAM.
+ Vous devrez créer ou utiliser des ressources Kubernetes `Role`/`ClusterRole` et `RoleBinding`/`ClusterRoleBinding` qui référencent ces groupes.
1. Déterminez si le nom d’utilisateur généré automatiquement convient à l’entrée d’accès ou si vous devez spécifier manuellement un nom d’utilisateur.
+ AWS génère automatiquement cette valeur en fonction de l’identité IAM. Vous pouvez définir un nom d’utilisateur personnalisé. Cela est visible dans les journaux Kubernetes.
+ Pour de plus amples informations, consultez [Définir un nom d’utilisateur personnalisé pour les entrées d’accès Amazon EKS](set-custom-username.md).
## Étape 2 : créer une entrée d’accès avec des groupes Kubernetes
Après avoir planifié l’entrée d’accès, utilisez la CLI AWS pour la créer avec les groupes Kubernetes appropriés.
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD --kubernetes-groups
```
Remplacez :
+ `` par le nom de votre cluster EKS
+ `` par l’ARN de l’utilisateur ou du rôle IAM
+ `` par une liste de groupes Kubernetes séparés par des virgules (par exemple : « system:developers,system:readers »)
[Affichez la référence de la CLI pour toutes les options de configuration](https://docs.aws.amazon.com/cli/latest/reference/eks/create-access-entry.html).
## Étape 3 : configurer RBAC Kubernetes
Pour permettre au principal IAM d’accéder aux objets Kubernetes de votre cluster, vous devez créer et gérer les objets de contrôle d’accès basé sur les rôles (RBAC) dans Kubernetes :
1. Créez des objets Kubernetes `Role` ou `ClusterRole` qui définissent les autorisations.
1. Créez des objets Kubernetes `RoleBinding` ou `ClusterRoleBinding` sur votre cluster qui spécifient le nom du groupe sous forme de `subject` pour `kind: Group`.
Pour des informations détaillées sur la configuration des groupes et des autorisations dans Kubernetes, consultez la section [Utilisation de l’autorisation RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) dans la documentation Kubernetes.
## Étapes suivantes
+ [Création d’un fichier kubeconfig pour utiliser kubectl avec une identité IAM](create-kubeconfig.md)
# Accordez aux utilisateurs IAM l'accès à Kubernetes avec un ConfigMap
**Important**
`aws-auth ConfigMap` est obsolète. Pour connaître la méthode recommandée pour gérer l'accès à Kubernetes APIs, consultez. [Attribution de l’accès Kubernetes aux utilisateurs IAM avec les entrées d’accès EKS](access-entries.md)
L’accès à votre cluster à l’aide des [principaux IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) est activé par l’[authentificateur AWS IAM pour Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme), qui s’exécute sur le plan de contrôle Amazon EKS. L'authentificateur obtient ses informations de configuration à partir du `aws-auth` `ConfigMap`. Pour tous les paramètres `aws-auth` `ConfigMap`, consultez [Format de configuration complet](https://github.com/kubernetes-sigs/aws-iam-authenticator#full-configuration-format) sur GitHub.
## Ajout de principaux IAM à votre cluster Amazon EKS
Lorsque vous créez un cluster Amazon EKS, le [principal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) qui crée le cluster se voit automatiquement accorder des autorisations `system:masters` dans la configuration du contrôle d’accès basé sur les rôles (RBAC) du cluster dans le plan de contrôle Amazon EKS. Ce principal n’apparaît dans aucune configuration visible. Souvenez-vous donc du principal qui a créé le cluster à l’origine. Pour accorder à d’autres principaux IAM la possibilité d’interagir avec votre cluster, modifiez le `aws-auth ConfigMap` dans Kubernetes et créez un `rolebinding` ou `clusterrolebinding` Kubernetes associé au nom d’un `group` que vous spécifiez dans le `aws-auth ConfigMap`.
**Note**
Pour plus d’informations sur la configuration du contrôle d’accès basé sur les rôles (RBAC) de Kubernetes, consultez la section [Utilisation de l’autorisation RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) dans la documentation Kubernetes.
1. Déterminer les informations d'identification que `kubectl` utilise pour accéder à votre cluster. Sur votre ordinateur, vous pouvez voir quelles informations d'identification `kubectl` utilise avec la commande suivante. *\$1/.kube/config*Remplacez-le par le chemin de votre `kubeconfig` fichier si vous n'utilisez pas le chemin par défaut.
```
cat ~/.kube/config
```
L'exemple qui suit illustre un résultat.
```
[...]
contexts:
- context:
cluster: my-cluster.region-code.eksctl.io
user: admin@my-cluster.region-code.eksctl.io
name: admin@my-cluster.region-code.eksctl.io
current-context: admin@my-cluster.region-code.eksctl.io
[...]
```
Dans l'exemple de sortie précédent, les informations d'identification d'un utilisateur nommé *admin* sont configurées pour un cluster nommé *my-cluster*. Si c'est l'utilisateur qui a créé le cluster, alors il a déjà accès à votre cluster. S’il ne s’agit pas de l’utilisateur qui a créé le cluster, suivez les étapes restantes pour permettre à d’autres principaux IAM d’accéder au cluster. Les [bonnes pratiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) recommandent d'accorder des autorisations à des rôles plutôt qu'à des utilisateurs. Vous pouvez voir quels autres principaux ont actuellement accès à votre cluster à l'aide de la commande suivante :
```
kubectl describe -n kube-system configmap/aws-auth
```
L'exemple qui suit illustre un résultat.
```
Name: aws-auth
Namespace: kube-system
Labels:
Annotations:
Data
====
mapRoles:
----
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws: iam::111122223333:role/my-node-role
username: system:node:{{EC2PrivateDNSName}}
BinaryData
====
Events:
```
L'exemple précédent est un `aws-auth` `ConfigMap` par défaut. Seul le rôle d'instance du nœud a accès au cluster.
1. Assurez-vous de disposer de `roles` et `rolebindings` ou de `clusterroles` et `clusterrolebindings` existants auxquels vous pouvez associer des principaux IAM. Pour plus d'informations sur ces ressources, consultez [Utilisation de l'autorisation RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) dans la documentation Kubernetes.
1. Affichez vos `roles` ou `clusterroles` Kubernetes existants. Les `Roles` sont associés à un `namespace`, mais les `clusterroles` sont associés au cluster.
```
kubectl get roles -A
```
```
kubectl get clusterroles
```
1. Affichez les détails de tout `role` ou `clusterrole` renvoyé dans la sortie précédente et assurez-vous qu'il dispose des autorisations (`rules`) dont vous souhaitez que vos principaux IAM disposent dans votre cluster.
Remplacez *role-name* par un nom de `role` renvoyé dans la sortie de la commande précédente. Remplacez *kube-system* par l'espace de noms du `role`.
```
kubectl describe role role-name -n kube-system
```
Remplacez *cluster-role-name* par un nom de `clusterrole` renvoyé dans la sortie de la commande précédente.
```
kubectl describe clusterrole cluster-role-name
```
1. Affichez vos `rolebindings` ou `clusterrolebindings` Kubernetes existants. Les `Rolebindings` sont associés à un `namespace`, mais les `clusterrolebindings` sont associés au cluster.
```
kubectl get rolebindings -A
```
```
kubectl get clusterrolebindings
```
1. Affichez les détails de n'importe quel `rolebinding` ou `clusterrolebinding` et confirmez qu'il possède un `role` ou un `clusterrole` de l'étape précédente répertorié comme un `roleRef` et un nom de groupe répertorié pour `subjects`.
Remplacez *role-binding-name* par un nom de `rolebinding` renvoyé dans la sortie de la commande précédente. Remplacez *kube-system* avec le `namespace` du `rolebinding`.
```
kubectl describe rolebinding role-binding-name -n kube-system
```
L'exemple qui suit illustre un résultat.
```
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: eks-console-dashboard-restricted-access-role-binding
namespace: default
subjects:
- kind: Group
name: eks-console-dashboard-restricted-access-group
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: eks-console-dashboard-restricted-access-role
apiGroup: rbac.authorization.k8s.io
```
Remplacez *cluster-role-binding-name* par un nom de `clusterrolebinding` renvoyé dans la sortie de la commande précédente.
```
kubectl describe clusterrolebinding cluster-role-binding-name
```
L'exemple qui suit illustre un résultat.
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: eks-console-dashboard-full-access-binding
subjects:
- kind: Group
name: eks-console-dashboard-full-access-group
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: eks-console-dashboard-full-access-clusterrole
apiGroup: rbac.authorization.k8s.io
```
1. Modifiez le `aws-auth` `ConfigMap`. Vous pouvez utiliser un outil tel que `eksctl` pour mettre à jour le `ConfigMap` ou vous pouvez le mettre à jour manuellement en le modifiant.
**Important**
Nous vous recommandons d'utiliser `eksctl`, ou un autre outil, pour modifier le `ConfigMap`. Pour plus d'informations sur les autres outils que vous pouvez utiliser, consultez la section [Utiliser des outils pour apporter des modifications à l'aws- authConfigMap](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#use-tools-to-make-changes-to-the-aws-auth-configmap) dans les guides de bonnes pratiques Amazon EKS. Un `aws-auth` `ConfigMap` mis en forme incorrectement peut entraîner la perte de l'accès à votre cluster.
+ Consultez les étapes pour [modifier configmap avec eksctl](#configmap-eksctl).
+ Consultez les étapes pour [modifier configmap manuellement](#configmap-manual).
### Modification du ConfigMap avec eksctl
1. Vous avez besoin d'`0.215.0`une version ou d'une version ultérieure de l'outil de ligne de `eksctl` commande 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. Affichez les mappages actuels dans le `ConfigMap`. Remplacez *my-cluster* par le nom de votre cluster. Remplacez *region-code* par la AWS région dans laquelle se trouve votre cluster.
```
eksctl get iamidentitymapping --cluster my-cluster --region=region-code
```
L'exemple qui suit illustre un résultat.
```
ARN USERNAME GROUPS ACCOUNT
arn:aws: iam::111122223333:role/eksctl-my-cluster-my-nodegroup-NodeInstanceRole-1XLS7754U3ZPA system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
```
1. Ajoutez un mappage pour un rôle. Remplacez *my-role* par le nom de votre rôle. Remplacez *eks-console-dashboard-full-access-group* par le nom du groupe spécifié dans votre Kubernetes `RoleBinding` ou votre objet. `ClusterRoleBinding` Remplacez *111122223333* par votre ID de compte. Vous pouvez remplacer *admin* par n'importe quel nom que vous choisissez.
```
eksctl create iamidentitymapping --cluster my-cluster --region=region-code \
--arn arn:aws: iam::111122223333:role/my-role --username admin --group eks-console-dashboard-full-access-group \
--no-duplicate-arns
```
**Important**
L’ARN de rôle ne peut pas inclure de chemin d’accès tel que `role/my-team/developers/my-role`. Le format de l'ARN doit être ` arn:aws: iam::111122223333:role/my-role `. Dans cet exemple, `my-team/developers/` doit être supprimé.
L'exemple qui suit illustre un résultat.
```
[...]
2022-05-09 14:51:20 [ℹ] adding identity "{arn-aws}iam::111122223333:role/my-role" to auth ConfigMap
```
1. Ajoutez un mappage pour un utilisateur. Les [bonnes pratiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) recommandent d'accorder des autorisations à des rôles plutôt qu'à des utilisateurs. Remplacez *my-user* par votre nom d'utilisateur. Remplacez *eks-console-dashboard-restricted-access-group* par le nom du groupe spécifié dans votre Kubernetes `RoleBinding` ou votre objet. `ClusterRoleBinding` Remplacez *111122223333* par votre ID de compte. Vous pouvez remplacer *my-user* par n'importe quel nom que vous choisissez.
```
eksctl create iamidentitymapping --cluster my-cluster --region=region-code \
--arn arn:aws: iam::111122223333:user/my-user --username my-user --group eks-console-dashboard-restricted-access-group \
--no-duplicate-arns
```
L'exemple qui suit illustre un résultat.
```
[...]
2022-05-09 14:53:48 [ℹ] adding identity "arn:aws: iam::111122223333:user/my-user" to auth ConfigMap
```
1. Affichez de nouveau les mappages dans le `ConfigMap`.
```
eksctl get iamidentitymapping --cluster my-cluster --region=region-code
```
L'exemple qui suit illustre un résultat.
```
ARN USERNAME GROUPS ACCOUNT
arn:aws: iam::111122223333:role/eksctl-my-cluster-my-nodegroup-NodeInstanceRole-1XLS7754U3ZPA system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
arn:aws: iam::111122223333:role/admin my-role eks-console-dashboard-full-access-group
arn:aws: iam::111122223333:user/my-user my-user eks-console-dashboard-restricted-access-group
```
### Modification manuelle du ConfigMap
1. Ouvrez le `ConfigMap` pour le modifier.
```
kubectl edit -n kube-system configmap/aws-auth
```
**Note**
Si vous recevez un message d'erreur indiquant `Error from server (NotFound): configmaps "aws-auth" not found` « », utilisez la procédure décrite dans [Appliquer l'aws-auth ConfigMap à votre cluster](#aws-auth-configmap) pour appliquer le stock. `ConfigMap`
1. Ajoutez vos principaux IAM à la `ConfigMap`. Un groupe IAM n’est pas un principal IAM et ne peut donc pas être ajouté au `ConfigMap`.
+ **Pour ajouter un rôle IAM (par exemple, pour les [utilisateurs fédérés](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)) :** ajoutez les détails du rôle à la section `mapRoles` du `ConfigMap`, sous `data`. Ajoutez cette section si elle n'existe pas déjà dans le fichier. Chaque entrée prend en charge les paramètres suivants :
+ **rolearn** : ARN du rôle IAM à ajouter. Cette valeur ne peut pas contenir de chemin. Par exemple, vous ne pouvez pas spécifier un ARN tel que ` arn:aws: iam::111122223333:role/my-team/developers/role-name `. L'ARN doit être ` arn:aws: iam::111122223333:role/role-name `.
+ **username** : nom d'utilisateur dans Kubernetes à mapper au rôle IAM.
+ **groups** : groupe ou liste des groupes Kubernetes auxquels mapper le rôle. Le groupe peut être un groupe par défaut ou un groupe spécifié dans un `clusterrolebinding` ou `rolebinding`. Pour plus d’informations, consultez [Rôles par défaut et liaisons de rôles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) dans la documentation Kubernetes.
+ **Pour ajouter un utilisateur IAM :** les [bonnes pratiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) recommandent d'accorder des autorisations à des rôles plutôt qu'à des utilisateurs. Ajoutez les détails de l'utilisateur dans la section `mapUsers` de la `ConfigMap`, sous `data`. Ajoutez cette section si elle n'existe pas déjà dans le fichier. Chaque entrée prend en charge les paramètres suivants :
+ **userarn** : ARN de l'utilisateur IAM à ajouter.
+ **username** : nom d'utilisateur dans Kubernetes à mapper à l'utilisateur IAM.
+ **groups** : groupe ou liste des groupes Kubernetes auxquels mapper l'utilisateur. Le groupe peut être un groupe par défaut ou un groupe spécifié dans un `clusterrolebinding` ou `rolebinding`. Pour plus d’informations, consultez [Rôles par défaut et liaisons de rôles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) dans la documentation Kubernetes.
1. Par exemple, le bloc YAML ci-dessous contient :
+ Une section `mapRoles` qui mappe l'instance du nœud IAM avec des groupes Kubernetes afin que les nœuds puissent s'inscrire eux-mêmes avec le cluster et le rôle IAM `my-console-viewer-role` mappé à un groupe Kubernetes pouvant afficher toutes les ressources Kubernetes pour tous les clusters. Pour obtenir la liste des autorisations de groupe IAM et Kubernetes requises pour le rôle IAM `my-console-viewer-role`, voir [Autorisations requises](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
+ `mapUsers`Section qui fait correspondre l'utilisateur `admin` IAM du AWS compte par défaut au groupe `system:masters` Kubernetes et l'`my-user`utilisateur d'un autre AWS compte mappé à un groupe Kubernetes qui peut afficher les ressources Kubernetes pour un espace de noms spécifique. Pour obtenir la liste des autorisations de groupe IAM et Kubernetes requises pour l'utilisateur IAM `my-user`, voir [Autorisations requises](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
Ajoutez ou supprimez des lignes si nécessaire et remplacez toutes les valeurs d’exemple par vos propres valeurs.
```
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws: iam::111122223333:role/my-role
username: system:node:{{EC2PrivateDNSName}}
- groups:
- eks-console-dashboard-full-access-group
rolearn: arn:aws: iam::111122223333:role/my-console-viewer-role
username: my-console-viewer-role
mapUsers: |
- groups:
- system:masters
userarn: arn:aws: iam::111122223333:user/admin
username: admin
- groups:
- eks-console-dashboard-restricted-access-group
userarn: arn:aws: iam::444455556666:user/my-user
username: my-user
```
1. Enregistrez le fichier et quittez votre éditeur de texte.
## Appliquer la `ConfigMap` `aws-auth` à votre cluster
Le `aws-auth` `ConfigMap` est automatiquement créé et appliqué à votre cluster lorsque vous créez un groupe de nœuds géré ou lorsque vous créez un groupe de nœuds à l'aide de `eksctl`. Il est initialement créé pour permettre aux nœuds de rejoindre votre cluster, mais vous utilisez également cette `ConfigMap` pour ajouter un accès RBAC aux principaux IAM. Si vous avez lancé des nœuds autogérés et que vous n’avez pas appliqué le `ConfigMap` `aws-auth` à votre cluster, vous pouvez le faire à l’aide de la procédure suivante.
1. Vérifiez si vous avez déjà appliqué le `ConfigMap` `aws-auth`.
```
kubectl describe configmap -n kube-system aws-auth
```
Si vous recevez une erreur indiquant « `Error from server (NotFound): configmaps "aws-auth" not found` », appliquez le `ConfigMap` par défaut en suivant les étapes ci-dessous.
1. Téléchargez, modifiez et appliquez le plan de configuration de l' AWS authentificateur.
1. Téléchargez la mappe de configuration.
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml
```
1. Dans le fichier `aws-auth-cm.yaml`, remplacez `rolearn` par l'Amazon Resource Name (ARN) du rôle IAM associé par vos nœuds. Pour ce faire, utilisez un éditeur de texte ou remplacez *my-node-instance-role* et exécutez la commande suivante :
```
sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml
```
Ne modifiez aucune autre ligne de ce fichier.
**Important**
L’ARN de rôle ne peut pas inclure de chemin d’accès tel que `role/my-team/developers/my-role`. Le format de l'ARN doit être ` arn:aws: iam::111122223333:role/my-role `. Dans cet exemple, `my-team/developers/` doit être supprimé.
Vous pouvez inspecter les sorties de la AWS CloudFormation pile pour vos groupes de nœuds et rechercher les valeurs suivantes :
+ **InstanceRoleARN** — Pour les groupes de nœuds créés avec `eksctl`
+ **NodeInstanceRole**— Pour les groupes de nœuds créés à l'aide de AWS CloudFormation modèles Amazon EKS vendus dans le AWS Management Console
1. Appliquez la configuration. L'exécution de cette commande peut prendre quelques minutes.
```
kubectl apply -f aws-auth-cm.yaml
```
**Note**
Si vous recevez d'autres erreurs concernant les types d'autorisations ou de ressources, consultez [Accès non autorisé ou refusé (`kubectl`)](troubleshooting.md#unauthorized) dans la rubrique relative à la résolution des problèmes.
1. Observez le statut de vos nœuds et attendez qu'ils obtiennent le statut `Ready`.
```
kubectl get nodes --watch
```
Saisissez `Ctrl`\$1`C` pour revenir à une invite de shell.
# Accès des utilisateurs à Kubernetes via un fournisseur OIDC externe
Amazon EKS prend en charge l'utilisation des fournisseurs d'identité OpenID Connect (OIDC) comme méthode d'authentification des utilisateurs de votre cluster. Les fournisseurs d'identité OIDC peuvent être utilisés avec ou comme alternative à AWS Identity and Access Management (IAM). Pour plus d'informations sur l'utilisation d'IAM, consultez [Accorder aux utilisateurs et aux rôles IAM l'accès à Kubernetes APIs](grant-k8s-access.md). Après avoir configuré l'authentification dans votre cluster, vous pouvez créer des `roles` et des `clusterroles` Kubernetes pour attribuer des autorisations aux rôles, puis lier les rôles aux identités à l'aide de liaisons `rolebindings` et `clusterrolebindings` Kubernetes. Pour plus d'informations, consultez [Utilisation de l'autorisation RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) dans la documentation Kubernetes.
+ Vous pouvez associer un fournisseur d'identité OIDC à votre cluster.
+ Kubernetes ne fournit pas de fournisseur d’identité OIDC. Vous pouvez utiliser un fournisseur d'identité OIDC public existant ou vous exécuter votre propre fournisseur d'identité. Pour obtenir la liste des fournisseurs certifiés, consultez [Certification OpenID](https://openid.net/certification/) sur le site OpenID.
+ L'URL de l'émetteur du fournisseur d'identité OIDC doit être accessible publiquement, afin qu'Amazon EKS puisse découvrir les clés de signature. Amazon EKS ne prend pas en charge les fournisseurs d’identité OIDC utilisant des certificats autosignés.
+ Vous ne pouvez pas désactiver l’authentification IAM de votre cluster, car elle reste nécessaire pour joindre des nœuds au cluster.
+ Un cluster Amazon EKS doit cependant être créé par un [principal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) AWS plutôt que par un utilisateur de fournisseur d'identité OIDC. Cela est dû au fait que le créateur du cluster interagit avec Amazon EKS APIs plutôt qu'avec APIs Kubernetes.
+ Les utilisateurs authentifiés par le fournisseur d'identité OIDC sont répertoriés dans le journal d'audit du cluster si les CloudWatch journaux sont activés pour le plan de contrôle. Pour de plus amples informations, veuillez consulter [Activer ou désactiver les journaux du plan de contrôle](control-plane-logs.md#enabling-control-plane-log-export).
+ Vous ne pouvez pas vous connecter au AWS Management Console avec un compte auprès d'un fournisseur OIDC. Vous ne pouvez le faire qu'en vous [Consultez les ressources Kubernetes dans le AWS Management Console](view-kubernetes-resources.md) connectant AWS Management Console à l'aide d'un compte AWS Identity and Access Management.
## Associer un fournisseur d'identité OIDC
Pour pouvoir associer un fournisseur d'identité OIDC à votre cluster, vous devez obtenir les informations suivantes de votre fournisseur :
**URL de l'émetteur**
L'URL du fournisseur d'identité OIDC qui permet au serveur d'API de découvrir les clés de signature publiques pour vérifier les jetons. L’URL doit commencer par `https://` et correspondre à la revendication `iss` figurant dans les jetons d’ID OIDC du fournisseur. Conformément à la norme OIDC, les composants du chemin sont autorisés, mais pas les paramètres de requête. Généralement, l'URL se compose uniquement d'un nom d'hôte, comme `https://server.example.org` ou `https://example.com`. Cette URL doit pointer vers le niveau sous `.well-known/openid-configuration` et doit être accessible publiquement sur Internet.
**ID client (également appelé *audience*)**
L'ID de l'application cliente qui envoie les demandes d'authentification au fournisseur d'identité OIDC.
Vous pouvez associer un fournisseur d'identité à l'aide de `eksctl` ou de la AWS Management Console.
### Association d’un fournisseur d’identité à l’aide d’eksctl
1. Créez un fichier nommé `associate-identity-provider.yaml` avec les contenus suivants. Remplacez les exemples de valeurs par les vôtres. Les valeurs de la section `identityProviders` sont obtenues de votre fournisseur d'identité OIDC. Des valeurs ne sont requises que pour les paramètres `name`, `type`, `issuerUrl` et `clientId` sous `identityProviders`.
```
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: your-region-code
identityProviders:
- name: my-provider
type: oidc
issuerUrl: https://example.com
clientId: kubernetes
usernameClaim: email
usernamePrefix: my-username-prefix
groupsClaim: my-claim
groupsPrefix: my-groups-prefix
requiredClaims:
string: string
tags:
env: dev
```
**Important**
Ne spécifiez pas `system:`, ni aucune portion de cette chaîne, pour `groupsPrefix` ou `usernamePrefix`.
1. Créez le fournisseur.
```
eksctl associate identityprovider -f associate-identity-provider.yaml
```
1. Pour utiliser `kubectl` avec votre cluster et un fournisseur d’identité OIDC, consultez [Utilisation de kubectl](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl) dans la documentation Kubernetes.
### Associer un fournisseur d'identité à l'aide de la AWS console
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Sélectionnez votre cluster, puis sélectionnez l’onglet **Accès**.
1. Dans la section **Fournisseurs d’identité OIDC**, sélectionnez Associer un fournisseur d’identité.
1. Sur la page **Associate OIDC Identity Provider (Associer un fournisseur d'identité OIDC)**, saisissez ou sélectionnez les options suivantes, puis sélectionnez **Associate (Associer)**.
+ Dans **Nom**, saisissez un nom unique pour le fournisseur.
+ Pour **URL de l'émetteur**, saisissez l'URL de votre fournisseur. Cette URL doit être accessible via Internet.
+ Pour **ID client**, saisissez l’ID client du fournisseur d’identité OIDC (également appelé **audience**).
+ Pour **Nom d'utilisateur**, saisissez la revendication à utiliser comme nom d'utilisateur.
+ Pour **Revendication de groupes**, saisissez la revendication à utiliser comme groupe de l’utilisateur.
+ (Facultatif) Sélectionnez **Options avancées**, puis saisissez ou sélectionnez les informations suivantes :
+ **Nom d'utilisateur** : saisissez un préfixe à ajouter aux revendications de nom d'utilisateur. Le préfixe est ajouté aux revendications de nom d'utilisateur pour éviter les conflits avec les noms existants. Si vous ne fournissez aucune valeur et que le nom d'utilisateur est une valeur autre que `email`, le préfixe correspond par défaut à la valeur **URL de l'émetteur**. Vous pouvez utiliser la valeur ` -` pour désactiver toutes les préfixes. Ne spécifiez pas `system:` ni aucune partie de cette chaîne.
+ **Préfixe de groupes** : saisissez un préfixe à ajouter aux revendications de groupes. Le préfixe est ajouté aux revendications de groupe pour éviter les conflits avec des noms existants (tels que ` system: groups`). Par exemple, la valeur `oidc:` crée des noms de groupe comme `oidc:engineering` et `oidc:infra`. Ne spécifiez pas `system:` ni aucune partie de cette chaîne.
+ **Revendications requises** : sélectionnez **Ajouter une revendication** et saisissez une ou plusieurs paires de valeurs clés qui décrivent les revendications requises dans le jeton d'ID de client. Les paires décrivent les revendications requises dans le jeton d’ID. Si elle est définie, la présence de chaque revendication est vérifiée dans le jeton d'ID avec une valeur correspondante.
1. Pour utiliser `kubectl` avec votre cluster et un fournisseur d’identité OIDC, consultez [Utilisation de kubectl](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl) dans la documentation Kubernetes.
## Exemple de politique IAM
Si vous voulez empêcher un fournisseur d'identité OIDC d'être associé à un cluster, créez et associez la politique IAM suivante aux comptes IAM de vos administrateurs Amazon EKS. Pour plus d’informations, consultez [Création de politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) et [Ajout d’autorisations d’identité IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console) dans le *Guide de l’utilisateur IAM*, ainsi que [Actions](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerserviceforkubernetes.html) dans la Référence d’autorisation de service.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "denyOIDC",
"Effect": "Deny",
"Action": [
"eks:AssociateIdentityProviderConfig"
],
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/*"
},
{
"Sid": "eksAdmin",
"Effect": "Allow",
"Action": [
"eks:*"
],
"Resource": "*"
}
]
}
```
L'exemple de politique suivant autorise l'association de fournisseur d'identité OIDC si `clientID` est `kubernetes` et `issuerUrl` est `https://cognito-idp.us-west-2amazonaws.com/*`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCognitoOnly",
"Effect": "Deny",
"Action": "eks:AssociateIdentityProviderConfig",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-instance",
"Condition": {
"StringNotLikeIfExists": {
"eks:issuerUrl": "https://cognito-idp.us-west-2.amazonaws.com/*"
}
}
},
{
"Sid": "DenyOtherClients",
"Effect": "Deny",
"Action": "eks:AssociateIdentityProviderConfig",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-instance",
"Condition": {
"StringNotEquals": {
"eks:clientId": "kubernetes"
}
}
},
{
"Sid": "AllowOthers",
"Effect": "Allow",
"Action": "eks:*",
"Resource": "*"
}
]
}
```
# Dissocier un fournisseur d'identité OIDC de votre cluster
Si vous dissociez un fournisseur d'identité OIDC de votre cluster, les utilisateurs inclus dans le fournisseur ne peuvent plus accéder au cluster. Cependant, vous pouvez toujours accéder au cluster avec les [principaux IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal).
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dans la section **Fournisseurs d'identité OIDC**, sélectionnez **Dissocier**, saisissez le nom du fournisseur d'identité, puis sélectionnez `Disassociate`.
# Consultez les ressources Kubernetes dans le AWS Management Console
Vous pouvez afficher les ressources Kubernetes déployées sur votre cluster avec la AWS Management Console. [Vous ne pouvez pas afficher les ressources Kubernetes avec la AWS CLI ou eksctl.](https://eksctl.io/) Pour afficher les ressources Kubernetes à l’aide d’un outil en ligne de commande, utilisez [kubectl](install-kubectl.md).
**Note**
Pour afficher l'onglet **Ressources** et la section **Nœuds** de l'onglet **Compute** du AWS Management Console, le [principal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que vous utilisez doit disposer d'autorisations IAM et Kubernetes spécifiques. Pour de plus amples informations, veuillez consulter [Autorisations requises](#view-kubernetes-resources-permissions).
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dans la liste **Clusters**, sélectionnez le cluster qui contient les ressources Kubernetes que vous souhaitez afficher.
1. Sélectionnez l'onglet **Resources** (Ressources).
1. Sélectionnez un groupe **Resource type** (Type de ressource) pour lequel vous souhaitez afficher les ressources, comme **Workloads** (Charges de travail). Vous voyez une liste des types de ressources dans ce groupe.
1. Sélectionnez un type de ressource, tel que **Deployments** (Déploiements), dans le groupe **Workloads** (Charges de travail). Vous voyez une description du type de ressource, un lien vers la documentation Kubernetes pour plus d'informations sur le type de ressource et une liste des ressources de ce type qui sont déployées sur votre cluster. Si la liste est vide, aucune ressource de ce type n'est déployée sur votre cluster.
1. Sélectionnez une ressource pour afficher plus d'informations à son sujet. Essayez les exemples suivants :
+ Sélectionnez le groupe **Workloads** (Charges de travail), sélectionnez le type de ressource **Deployments** (Déploiements), puis sélectionnez la ressource **coredns**. Lorsque vous sélectionnez une ressource, vous êtes dans **Structured view** (Vue structurée), par défaut. Pour certains types de ressources, vous voyez une section **Pod** dans **Structured view** (Vue structurée). Cette section répertorie les pods gérés par la charge de travail. Vous pouvez sélectionner n’importe quel pod répertorié pour afficher des informations à son sujet. Tous les types de ressources n'affichent pas d'informations dans **Structured View** (Vue structurée). Si vous sélectionnez **Raw view** (Vue brute) dans le coin supérieur droit de la page de la ressource, vous voyez la réponse JSON complète de l'API Kubernetes pour la ressource.
+ Sélectionnez le groupe **Cluster**, puis sélectionnez le type de ressource **Nodes** (Nœuds). Vous voyez une liste de tous les nœuds de votre cluster. Les nœuds peuvent être n'importe quel [type de nœud Amazon EKS](eks-compute.md). Il s'agit de la même liste que celle que vous voyez dans la section **Nodes** (Nœuds) lorsque vous sélectionnez l'onglet **Compute** (Calcul) pour votre cluster. Sélectionnez une ressource de nœud dans la liste. Dans **Structured view** (Vue structurée), vous voyez également une section **Pod**. Cette section vous montre tous les pods s’exécutant sur le nœud.
## Autorisations requises
Pour afficher l'onglet **Ressources** et la section **Nœuds** de l'onglet **Compute** du AWS Management Console, le [principal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que vous utilisez doit disposer d'autorisations IAM et Kubernetes minimales spécifiques. Les autorisations IAM et Kubernetes RBAC doivent être correctement configurées. Procédez comme suit pour accorder les autorisations requises à vos principaux IAM.
1. Veuillez vous assurer que les autorisations `eks:AccessKubernetesApi` et autres autorisations IAM nécessaires pour afficher les ressources Kubernetes sont attribuées au principal IAM que vous utilisez. Pour plus d'informations sur la modification des autorisations d'un principal IAM, consultez la rubrique [Contrôle de l'accès des principaux](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html#access_controlling-principals) du Guide de l'utilisateur IAM. Pour plus d'informations sur la modification des autorisations pour un rôle, consultez [Modification d'une politique d'autorisations de rôle (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html#roles-modify_permissions-policy) dans le guide de l'utilisateur IAM.
L’exemple de politique suivant inclut les autorisations nécessaires pour qu’un principal puisse afficher les ressources Kubernetes pour tous les clusters de votre compte. Remplacez *111122223333* par votre identifiant de AWS compte.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:ListFargateProfiles",
"eks:DescribeNodegroup",
"eks:ListNodegroups",
"eks:ListUpdates",
"eks:AccessKubernetesApi",
"eks:ListAddons",
"eks:DescribeCluster",
"eks:DescribeAddonVersions",
"eks:ListClusters",
"eks:ListIdentityProviderConfigs",
"iam:ListRoles"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ssm:GetParameter",
"Resource": "arn:aws:ssm:*:111122223333:parameter/*"
}
]
}
```
Pour afficher les nœuds des [clusters connectés](eks-connector.md), le [rôle IAM du connecteur Amazon EKS](connector-iam-role.md) doit être en mesure d'emprunter l'identité du principal dans le cluster. Cela permet à [Amazon EKS Connector](eks-connector.md) de mapper le principal à un utilisateur Kubernetes.
1. Configurez les autorisations RBAC Kubernetes à l'aide des entrées d'accès EKS.
**Que sont les entrées EKS Access ?**
Les entrées d'accès EKS constituent un moyen simplifié d'accorder aux principaux IAM (utilisateurs et rôles) l'accès à votre cluster Kubernetes. Au lieu de gérer manuellement les ressources Kubernetes RBAC et les entrées d'accès gèrent automatiquement le `aws-auth` ConfigMap mappage entre les autorisations IAM et Kubernetes à l'aide des politiques gérées fournies par. AWS Pour des informations détaillées sur les entrées d'accès, voir[Attribution de l’accès Kubernetes aux utilisateurs IAM avec les entrées d’accès EKS](access-entries.md). Pour plus d'informations sur les politiques d'accès disponibles et leurs autorisations, consultez la section Autorisations relatives [aux politiques d'accès](https://docs.aws.amazon.com/eks/latest/userguide/access-policy-permissions.html).
Vous pouvez attacher des autorisations Kubernetes aux entrées d’accès de deux façons :
+ **Utiliser une politique d'accès :** les politiques d'accès sont des modèles d'autorisations Kubernetes prédéfinis gérés par. AWS Ils fournissent des ensembles d'autorisations standardisés pour les cas d'utilisation courants.
+ **Référencer un groupe Kubernetes :** si vous associez une identité IAM à un groupe Kubernetes, vous pouvez créer des ressources Kubernetes qui accordent des autorisations au groupe. Pour plus d'informations, consultez [Utilisation de l'autorisation RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) dans la documentation Kubernetes.
1. Créez une entrée d'accès pour votre principal IAM à l'aide de la AWS CLI. Remplacez *my-cluster* par le nom de votre cluster. Remplacez *111122223333* par votre ID de compte.
```
aws eks create-access-entry \
--cluster-name my-cluster \
--principal-arn arn:aws: iam::111122223333:role/my-console-viewer-role
```
L'exemple qui suit illustre un résultat.
```
{
"accessEntry": {
"clusterName": "my-cluster",
"principalArn": "arn:aws: iam::111122223333:role/my-console-viewer-role",
"kubernetesGroups": [],
"accessEntryArn": "arn:aws: eks:region-code:111122223333:access-entry/my-cluster/role/111122223333/my-console-viewer-role/abc12345-1234-1234-1234-123456789012",
"createdAt": "2024-03-15T10:30:45.123000-07:00",
"modifiedAt": "2024-03-15T10:30:45.123000-07:00",
"tags": {},
"username": "arn:aws: iam::111122223333:role/my-console-viewer-role",
"type": "STANDARD"
}
}
```
1. Associez une politique à l'entrée d'accès. Pour consulter les ressources Kubernetes, utilisez : `AmazonEKSViewPolicy`
```
aws eks associate-access-policy \
--cluster-name my-cluster \
--principal-arn arn:aws: iam::111122223333:role/my-console-viewer-role \
--policy-arn arn:aws: eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
--access-scope type=cluster
```
L'exemple qui suit illustre un résultat.
```
{
"clusterName": "my-cluster",
"principalArn": "arn:aws: iam::111122223333:role/my-console-viewer-role",
"associatedAt": "2024-03-15T10:31:15.456000-07:00"
}
```
Pour un accès spécifique à un espace de noms, vous pouvez étendre la politique à des espaces de noms spécifiques :
```
aws eks associate-access-policy \
--cluster-name my-cluster \
--principal-arn arn:aws: iam::111122223333:role/my-console-viewer-role \
--policy-arn arn:aws: eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
--access-scope type=namespace,namespaces=default,kube-system
```
1. Vérifiez que l'entrée d'accès a bien été créée :
```
aws eks describe-access-entry \
--cluster-name my-cluster \
--principal-arn arn:aws: iam::111122223333:role/my-console-viewer-role
```
1. Répertoriez les politiques associées pour confirmer l'association des politiques :
```
aws eks list-associated-access-policies \
--cluster-name my-cluster \
--principal-arn arn:aws: iam::111122223333:role/my-console-viewer-role
```
L'exemple qui suit illustre un résultat.
```
{
"associatedAccessPolicies": [
{
"policyArn": "arn:aws: eks::aws:cluster-access-policy/AmazonEKSViewPolicy",
"accessScope": {
"type": "cluster"
},
"associatedAt": "2024-03-15T10:31:15.456000-07:00",
"modifiedAt": "2024-03-15T10:31:15.456000-07:00"
}
]
}
```
## CloudTrail visibilité
Lorsque vous consultez les ressources Kubernetes, le nom de l'opération suivant apparaît dans vos journaux : CloudTrail
+ `AccessKubernetesApi`- Lorsque vous lisez ou consultez des ressources
Cet CloudTrail événement fournit une piste d'audit de l'accès en lecture à vos ressources Kubernetes.
**Note**
Ce nom d'opération apparaît dans les CloudTrail journaux à des fins d'audit uniquement. Il ne s'agit pas d'une action IAM et ne peut pas être utilisée dans les déclarations de politique IAM. Pour contrôler l'accès en lecture aux ressources Kubernetes par le biais de politiques IAM, utilisez l'`eks:AccessKubernetesApi`autorisation indiquée dans la section. [Autorisations requises](#view-kubernetes-resources-permissions)
# Accorder AWS aux services l'accès en écriture à Kubernetes APIs
## Autorisations requises
Pour permettre aux AWS services d'effectuer des opérations d'écriture sur les ressources Kubernetes de votre cluster Amazon EKS, vous devez accorder à la fois les autorisations IAM `eks:AccessKubernetesApi` et `eks:MutateViaKubernetesApi` IAM.
Par exemple, Amazon SageMaker HyperPod utilise ces autorisations pour permettre le déploiement de modèles depuis SageMaker AI Studio. Pour plus d'informations, consultez la section [Configurer les autorisations facultatives du JavaScript SDK](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-model-deployment-setup.html#sagemaker-hyperpod-model-deployment-setup-optional-js) dans le manuel Amazon SageMaker AI Developer Guide.
**Important**
Les opérations d'écriture telles que la création, la mise à jour et la suppression nécessitent les deux autorisations. Si l'une d'entre elles est absente, les opérations d'écriture échoueront.
## CloudTrail visibilité
Lorsque vous effectuez des opérations d'écriture sur les ressources Kubernetes, vous verrez des noms d'opérations spécifiques dans vos journaux : CloudTrail
+ `createKubernetesObject`- Lors de la création de nouvelles ressources
+ `updateKubernetesObject`- Lors de la modification de ressources existantes
+ `deleteKubernetesObject`- Lors de la suppression de ressources
Ces CloudTrail événements fournissent des pistes d'audit détaillées de toutes les modifications apportées à vos ressources Kubernetes.
**Note**
Ces noms d'opérations apparaissent dans les CloudTrail journaux à des fins d'audit uniquement. Il ne s'agit pas d'actions IAM et ne peuvent pas être utilisées dans les déclarations de politique IAM. Pour contrôler l'accès en écriture aux ressources Kubernetes par le biais de politiques IAM, utilisez l'`eks:MutateViaKubernetesApi`autorisation indiquée dans la section. [Autorisations requises](#mutate-kubernetes-resources-permissions)
# Connexion de kubectl à un cluster EKS en créant un fichier kubeconfig
**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.
Dans cette rubrique, vous allez créer un fichier `kubeconfig` pour votre cluster (ou mettre à jour un fichier existant).
L'outil de ligne de commande `kubectl` utilise les informations de configuration dans les fichiers `kubeconfig` pour communiquer avec le serveur API d'un cluster. Pour plus d’informations, consultez [Organisation de l’accès au cluster à l’aide des fichiers kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) dans la documentation Kubernetes.
Amazon EKS utilise la commande `aws eks get-token` avec `kubectl` pour l'authentification du cluster. Par défaut, la AWS CLI utilise les mêmes informations d'identification que celles renvoyées par la commande suivante :
```
aws sts get-caller-identity
```
+ Un cluster Amazon EKS existant. Pour en déployer un, consultez [Mise en route avec Amazon EKS](getting-started.md).
+ 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).
+ 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*.
+ Un utilisateur IAM ou un rôle IAM avec l'autorisation d'utiliser l'action d'API `eks:DescribeCluster` pour le cluster que vous spécifiez. Pour de plus amples informations, veuillez consulter [Exemples de politiques basées sur l'identité d'Amazon EKS](security-iam-id-based-policy-examples.md). Si vous utilisez une identité provenant de votre propre fournisseur OpenID Connect pour accéder à votre cluster, consultez [Utilisation de kubectl](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl) dans la documentation Kubernetes afin de créer ou de mettre à jour votre fichier `kube config`.
## Créer le fichier `kubeconfig` automatiquement
+ 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*.
+ Autorisation d'utiliser l'action d'API `eks:DescribeCluster` pour le cluster que vous spécifiez. Pour de plus amples informations, veuillez consulter [Exemples de politiques basées sur l'identité d'Amazon EKS](security-iam-id-based-policy-examples.md).
1. Créez ou mettez à jour un fichier `kubeconfig` pour votre cluster. Remplacez *region-code* par la AWS région dans laquelle se trouve votre cluster et remplacez *my-cluster* par le nom de votre cluster.
```
aws eks update-kubeconfig --region region-code --name my-cluster
```
Par défaut, le fichier de configuration résultant est créé dans le chemin `kubeconfig` par défaut (`.kube`) dans votre répertoire de base ou fusionné avec un fichier `config` existant à cet emplacement. Vous pouvez spécifier un autre chemin avec l'option `--kubeconfig`.
Vous pouvez spécifier un ARN de rôle IAM avec l'option `--role-arn` à utiliser pour l'authentification lorsque vous émettez des commandes `kubectl`. Dans le cas contraire, le [principal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) de votre chaîne d'identification par défaut de la AWS CLI ou du SDK est utilisé. Vous pouvez consulter l'identité de votre AWS CLI ou de votre SDK par défaut en exécutant la `aws sts get-caller-identity` commande.
*Pour connaître toutes les options disponibles, exécutez la `aws eks update-kubeconfig help` commande ou consultez [update-kubeconfig dans](https://docs.aws.amazon.com/cli/latest/reference/eks/update-kubeconfig.html) le manuel de référence des commandes de la CLI AWS .*
1. Testez votre configuration.
```
kubectl get svc
```
L'exemple qui suit illustre un résultat.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc/kubernetes ClusterIP 10.100.0.1 443/TCP 1m
```
Si vous recevez d'autres erreurs concernant les types d'autorisations ou de ressources, consultez [Accès non autorisé ou refusé (`kubectl`)](troubleshooting.md#unauthorized) dans la rubrique relative à la résolution des problèmes.
# Accorder aux charges de travail Kubernetes l’accès à AWS à l’aide des comptes de service Kubernetes
[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
**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
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
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 <
1. Vérifiez que la stratégie d’approbation du rôle IAM est correctement configurée.
```
aws iam get-role --role-name my-role --query Role.AssumeRolePolicyDocument
```
L'exemple qui suit illustre un résultat.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account",
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
}
}
}
]
}
```
1. Vérifiez que la stratégie que vous avez associée à votre rôle lors d'une étape précédente est associée au rôle.
```
aws iam list-attached-role-policies --role-name my-role --query "AttachedPolicies[].PolicyArn" --output text
```
L'exemple qui suit illustre un résultat.
```
arn:aws: iam::111122223333:policy/my-policy
```
1. Définissez une variable pour stocker l'Amazon Resource Name (ARN) de la stratégie que vous souhaitez utiliser. *my-policy*Remplacez-le par le nom de la politique pour laquelle vous souhaitez confirmer les autorisations.
```
export policy_arn=arn:aws: iam::111122223333:policy/my-policy
```
1. Affichez la version par défaut de la stratégie.
```
aws iam get-policy --policy-arn $policy_arn
```
L'exemple qui suit illustre un résultat.
```
{
"Policy": {
"PolicyName": "my-policy",
"PolicyId": "EXAMPLEBIOWGLDEXAMPLE",
"Arn": "arn:aws: iam::111122223333:policy/my-policy",
"Path": "/",
"DefaultVersionId": "v1",
[...]
}
}
```
1. Consultez le contenu de la stratégie pour vous assurer qu’elle inclut toutes les autorisations nécessaires pour votre pod. Si nécessaire, remplacez *1* la commande suivante par la version renvoyée dans la sortie précédente.
```
aws iam get-policy-version --policy-arn $policy_arn --version-id v1
```
L'exemple qui suit illustre un résultat.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-pod-secrets-bucket"
}
]
}
```
Si vous avez créé l'exemple de stratégie lors d'une étape précédente, le résultat est le même. Si vous avez créé une politique différente, le *example* contenu est différent.
1. Confirmez que le compte de service Kubernetes est annoté avec le rôle.
```
kubectl describe serviceaccount my-service-account -n default
```
L'exemple qui suit illustre un résultat.
```
Name: my-service-account
Namespace: default
Annotations: eks.amazonaws.com/role-arn: arn:aws: iam::111122223333:role/my-role
Image pull secrets:
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
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 <
Si vous utilisez un compte de service Kubernetes avec des [rôles IAM pour les comptes de service](iam-roles-for-service-accounts.md), vous pouvez configurer le type de point de terminaison du service de jetons de sécurité AWS utilisé par le compte de service.
AWS recommande d’utiliser les points d’arrivée régionaux STS AWS plutôt que le point d’arrivée global. Cela réduit la latence, fournit une redondance intégrée et augmente la validité des jetons de session. Le service de jetons de sécurité AWS doit être actif dans la région AWS où le pod est exécuté. De plus, votre application doit disposer d’une redondance intégrée pour une autre région AWS en cas de défaillance du service dans la région AWS. Pour plus d’informations, consultez [Gestion d’AWS STS dans une région AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html) dans le Guide de l’utilisateur IAM.
+ 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 OIDC existant pour votre cluster. Pour de plus amples informations, 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 configuré pour être utilisé avec la fonction [Amazon EKS IAM pour les comptes de service](iam-roles-for-service-accounts.md).
Les exemples suivants utilisent tous le compte de service Kubernetes aws-node utilisé par le plug-in [Amazon VPC CNI](cni-iam-role.md). Vous pouvez remplacer les *valeurs d’exemple* par vos propres comptes de service, pods, espaces de noms et autres ressources.
1. Sélectionnez un pod qui utilise un compte de service dont vous souhaitez modifier le point de terminaison. Déterminez dans quelle région AWS le Pod fonctionne. Remplacez *aws-node-6mfgv* par le nom de votre pod et *kube-system* par l’espace de noms de votre pod.
```
kubectl describe pod aws-node-6mfgv -n kube-system |grep Node:
```
L'exemple qui suit illustre un résultat.
```
ip-192-168-79-166.us-west-2/192.168.79.166
```
Dans la sortie précédente, le Pod s’exécute sur un nœud dans la région AWS us-west-2.
1. Déterminez le type de point de terminaison utilisé par le compte de service du pod.
```
kubectl describe pod aws-node-6mfgv -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS
```
L'exemple qui suit illustre un résultat.
```
AWS_STS_REGIONAL_ENDPOINTS: regional
```
Si le point de terminaison actuel est international, alors `global` est renvoyé en sortie. Si aucune sortie n'est renvoyée, le type de point de terminaison par défaut est en cours d'utilisation et n'a pas été remplacé.
1. Si la version de votre cluster ou celle de votre plateforme est identique ou ultérieure à celles répertoriées dans le tableau, vous pouvez modifier le type de point de terminaison utilisé par votre compte de service pour le faire passer du type par défaut à un type différent à l'aide de l'une des commandes suivantes. Remplacez *aws-node* par le nom de votre compte de service et *kube-system* par l'espace de noms de votre compte de service.
+ Si votre type de point de terminaison par défaut ou actuel est international et que vous souhaitez le remplacer par régional :
```
kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=true
```
Si vous utilisez des [rôles IAM pour les comptes de service](iam-roles-for-service-accounts.md) afin de générer des URL S3 pré-signées dans votre application exécutée dans les conteneurs Pods, le format de l’URL pour les points de terminaison régionaux est similaire à l’exemple suivant :
```
https://bucket.s3.us-west-2.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...
```
+ Si votre type de point de terminaison par défaut ou actuel est régional et que vous souhaitez le remplacer par international :
```
kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=false
```
Si votre application envoie explicitement des requêtes aux points de terminaison globaux STS AWS et que vous ne remplacez pas le comportement par défaut consistant à utiliser les points de terminaison régionaux dans les clusters Amazon EKS, les requêtes échoueront et généreront une erreur. Pour de plus amples informations, consultez [Les conteneurs Pod reçoivent l'erreur suivante : `An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: Credential should be scoped to a valid region`](security-iam-troubleshoot.md#security-iam-troubleshoot-wrong-sts-endpoint).
Si vous utilisez des [rôles IAM pour les comptes de service](iam-roles-for-service-accounts.md) afin de générer des URL S3 pré-signées dans votre application exécutée dans les conteneurs Pods, le format de l’URL pour les points de terminaison globaux est similaire à l’exemple suivant :
```
https://bucket.s3.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...
```
Si votre automatisation nécessite une URL pré-signée dans un certain format ou si votre application ou les dépendances en aval qui utilisent des URL pré-signées ont des attentes concernant la région AWS ciblée, effectuez les modifications nécessaires pour utiliser le point de terminaison STS AWS approprié.
1. Supprimez et recréez tous les pods existants associés au compte de service pour appliquer les variables d’environnement des informations d’identification. Le hook web en mutation ne les applique pas aux qui sont déjà en cours d’exécution. Vous pouvez remplacer *pods*, *kube-system* et *-l k8s-app=aws-node* par les informations relatives aux pods pour lesquels vous avez défini votre annotation.
```
kubectl delete Pods -n kube-system -l k8s-app=aws-node
```
1. Vérifiez que les pods ont tous redémarré.
```
kubectl get Pods -n kube-system -l k8s-app=aws-node
```
1. Affichez les variables d’environnement pour l’un des pods. Vérifiez que la valeur `AWS_STS_REGIONAL_ENDPOINTS` est celle que vous avez définie à une étape précédente.
```
kubectl describe pod aws-node-kzbtr -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS
```
L'exemple qui suit illustre un résultat.
```
AWS_STS_REGIONAL_ENDPOINTS=regional
```
# Authentifiez-vous sur un autre compte avec IRSA
Vous pouvez configurer les autorisations IAM entre comptes en créant un fournisseur d’identité à partir du cluster d’un autre compte ou en utilisant les opérations `AssumeRole` chaînées. Dans les exemples suivants, le *compte A* possède un cluster Amazon EKS qui prend en charge les rôles IAM pour les comptes de service. Les pods qui s’exécutent sur ce cluster doivent assumer les autorisations IAM du *compte B*.
+ **L'option 1** est plus simple mais nécessite que le compte B crée et gère un fournisseur d'identité OIDC pour le cluster du compte A.
+ **L'option 2** conserve la gestion de l'OIDC dans le compte A mais nécessite un chaînage des rôles via deux `AssumeRole` appels.
## Option 1 : créer un fournisseur d'identité à partir du cluster d'un autre compte
Dans cet exemple, le Compte A fournit au Compte B l'URL de l'émetteur OpenID Connect (OIDC) à partir de son cluster. Le compte B suit les instructions de la section [Créer un fournisseur IAM OIDC pour votre cluster](enable-iam-roles-for-service-accounts.md) et [Attribution de rôles IAM aux comptes de service Kubernetes](associate-service-account-role.md) utilise l’URL d’émetteur OIDC du cluster du compte A. Ensuite, un administrateur de cluster annote le compte de service dans le cluster du compte A pour utiliser le rôle du compte B (*444455556666*).
```
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
eks.amazonaws.com/role-arn: arn:aws: iam::444455556666:role/account-b-role
```
## Option 2 : utiliser des opérations chaînées `AssumeRole`
Dans cette approche, chaque compte crée un rôle IAM. Le rôle du compte B fait confiance au compte A, et le rôle du compte A utilise la fédération OIDC pour obtenir les informations d'identification du cluster. Le Pod enchaîne ensuite les deux rôles à l'aide de profils AWS CLI.
### Étape 1 : créer le rôle cible dans le compte B
Le compte B (*444455556666*) crée un rôle IAM avec les autorisations dont ont besoin les pods du cluster du compte A. Le compte B associe la politique d'autorisation souhaitée à ce rôle, puis ajoute la politique de confiance suivante.
**Politique de confiance pour le rôle du compte B** — Cette politique permet au rôle IRSA spécifique du compte A d'assumer ce rôle.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
```
**Important**
Pour obtenir le moindre privilège, remplacez l'`Principal`ARN par l'ARN du rôle spécifique du compte A au lieu d'utiliser le compte root (`arn:aws:iam::111122223333:root`). L'utilisation de la racine du compte permet *à n'importe quel* principal IAM du compte A d'assumer ce rôle.
### Étape 2 : créer le rôle IRSA dans le compte A
Le compte A (*111122223333*) crée un rôle doté d'une politique de confiance qui obtient les informations d'identification du fournisseur d'identité créé avec l'adresse de l'émetteur OIDC du cluster.
**Politique de confiance pour le rôle du compte A (fédération OIDC)** — Cette politique permet au fournisseur OIDC du cluster EKS de délivrer des informations d'identification pour ce rôle.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
}
}
}
]
}
```
**Important**
Pour bénéficier du moindre privilège, ajoutez une `StringEquals` condition à la `sub` revendication visant à restreindre ce rôle à un compte de service Kubernetes spécifique. Sans `sub` condition, n'importe quel compte de service du cluster peut assumer ce rôle. La `sub` valeur utilise le format`system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME `. Par exemple, pour vous limiter à un compte de service nommé `my-service-account` dans l'espace de `default` noms :
```
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account"
```
### Étape 3 : associer l' AssumeRole autorisation au rôle du compte A
Le compte A associe une politique d'autorisation au rôle créé à l'étape 2. Cette politique permet au rôle d'assumer le rôle du compte B.
**Politique d'autorisation pour le rôle du compte A** — Cette politique accorde `sts:AssumeRole` le rôle cible du compte B.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::444455556666:role/account-b-role"
}
]
}
```
### Étape 4 : configurer le Pod pour enchaîner les rôles
Le code d’application permettant aux pods d’assumer le rôle du compte B utilise deux profils : `account_b_role` et `account_a_role`. Le profil `account_b_role` utilise le profil `account_a_role` comme source. Pour la AWS CLI, le `~/.aws/config` fichier est similaire au suivant.
```
[profile account_b_role]
source_profile = account_a_role
role_arn=arn:aws: iam::444455556666:role/account-b-role
[profile account_a_role]
web_identity_token_file = /var/run/secrets/eks.amazonaws.com/serviceaccount/token
role_arn=arn:aws: iam::111122223333:role/account-a-role
```
Pour spécifier des profils chaînés pour d'autres AWS SDKs, consultez la documentation du SDK que vous utilisez. Pour plus d'informations, consultez la section [Outils sur lesquels vous pouvez vous appuyer AWS](https://aws.amazon.com/developer/tools/).
# Utiliser IRSA avec le SDK AWS
**Utilisation des informations d’identification**
Pour utiliser les informations d’identification des rôles IAM des comptes de service (IRSA), votre code peut utiliser n’importe quel kit SDK AWS pour créer un client pour un service AWS avec un kit SDK, et par défaut, le kit SDK recherche dans une chaîne d’emplacements les informations d’identification de gestion des identités et des accès AWS à utiliser. Les informations d’identification des rôles IAM des comptes de service seront utilisées si vous ne spécifiez pas de fournisseur d’informations d’identification lors de la création du client ou de l’initialisation du kit SDK.
Cela fonctionne parce que les rôles IAM des comptes de service ont été ajoutés en tant qu’étape dans la chaîne d’informations d’identification par défaut. Si vos charges de travail utilisent actuellement des informations d’identification qui se trouvent plus haut dans la chaîne d’informations d’identification, ces informations d’identification continueront d’être utilisées même si vous configurez un rôle IAM des comptes de service pour la même charge de travail.
Le SDK échange automatiquement le jeton OIDC du compte de service contre des informations d’identification temporaires provenant du service de jetons de sécurité AWS à l’aide de l’action `AssumeRoleWithWebIdentity`. Amazon EKS et cette action du kit SDK poursuivent la rotation des informations d’identification temporaires en les renouvelant avant qu’elles n’expirent.
Lorsque vous utilisez des [rôles IAM pour les comptes de service](iam-roles-for-service-accounts.md), les conteneurs de vos pods doivent utiliser une version du SDK AWS qui prend en charge l’attribution d’un rôle IAM via un fichier de jetons d’identité Web OpenID Connect. Veillez à utiliser les versions suivantes, ou ultérieures, pour votre SDK AWS :
+ Java (version 2) – [2.10.11](https://github.com/aws/aws-sdk-java-v2/releases/tag/2.10.11)
+ Java : [1.12.782](https://github.com/aws/aws-sdk-java/releases/tag/1.12.782)
+ Kit SDK AWS pour Go v1 : [1.23.13](https://github.com/aws/aws-sdk-go/releases/tag/v1.23.13)
+ Kit SDK AWS pour Go v2 : toutes les versions sont prises en charge
+ Python (Boto3) – [1.9.220](https://github.com/boto/boto3/releases/tag/1.9.220)
+ Python (botocore) – [1.12.200](https://github.com/boto/botocore/releases/tag/1.12.200)
+ AWS CLI : [1.16.232](https://github.com/aws/aws-cli/releases/tag/1.16.232)
+ Node – [2.525.0](https://github.com/aws/aws-sdk-js/releases/tag/v2.525.0) et [3.27.0](https://github.com/aws/aws-sdk-js-v3/releases/tag/v3.27.0)
+ Ruby – [3.58.0](https://github.com/aws/aws-sdk-ruby/blob/version-3/gems/aws-sdk-core/CHANGELOG.md#3580-2019-07-01)
+ C\$1\$1 – [1.7.174](https://github.com/aws/aws-sdk-cpp/releases/tag/1.7.174)
+ .NET – [3.3.659.1](https://github.com/aws/aws-sdk-net/releases/tag/3.3.659.1) – Vous devez également inclure `AWSSDK.SecurityToken`.
+ PHP – [3.110.7](https://github.com/aws/aws-sdk-php/releases/tag/3.110.7)
De nombreux modules complémentaires Kubernetes populaires, tels que [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), [Routage du trafic Internet avec AWS Load Balancer Controller](aws-load-balancer-controller.md) et le [plug-in CNI Amazon VPC pour Kubernetes](cni-iam-role.md), prennent en charge les rôles IAM pour les comptes de service.
Pour vous assurer d’utiliser un kit SDK pris en charge, suivez les instructions d’installation relatives à votre SDK préféré de la page [Tools to Build on AWS](https://aws.amazon.com/tools/) lorsque vous créez vos conteneurs.
## Considérations
### Java
Lorsque vous utilisez Java, vous *devez* inclure le module `sts` dans le chemin de classe. Pour plus d’informations, consultez [WebIdentityTokenFileCredentialsProvider](https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/auth/credentials/WebIdentityTokenFileCredentialsProvider.html) dans la documentation du SDK Java.
# Récupérer les clés de signature pour valider les jetons OIDC
Kubernetes délivre un `ProjectedServiceAccountToken` à chaque compte de service Kubernetes. Ce jeton est un jeton OIDC, qui est lui-même un type de jeton web JSON (JWT). Amazon EKS héberge un point de terminaison OIDC public pour chaque cluster qui contient les clés de signature du jeton afin que les systèmes externes puissent le valider.
Pour valider un `ProjectedServiceAccountToken`, vous devez récupérer les clés de signature publiques OIDC, également appelées JSON Web Key Set (JWKS). Utilisez ces clés dans votre application pour valider le jeton. Par exemple, vous pouvez utiliser la [bibliothèque Python PyJWT](https://pyjwt.readthedocs.io/en/latest/) pour valider les jetons à l’aide de ces clés. Pour plus d’informations sur le `ProjectedServiceAccountToken`, consultez [Informations générales sur IAM, Kubernetes et OpenID Connect (OIDC)](iam-roles-for-service-accounts.md#irsa-oidc-background).
## Prérequis
+ Un fournisseur OpenID Connect (OIDC) existant pour la gestion des identités et des accès (IAM) AWS pour votre cluster. Pour déterminer si vous en avez déjà un, ou pour en créer un, consultez [Créer un fournisseur d'identité OIDC IAM pour votre cluster](enable-iam-roles-for-service-accounts.md).
+ ** AWS CLI** : Un outil de ligne de commande pour travailler avec les services AWS, y compris Amazon EKS. Pour plus d’informations, consultez la section [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) du Guide de l’utilisateur de l’interface de la ligne de commande AWS. Après avoir installé CLI AWS, nous vous recommandons de le configurer également. Pour plus d’informations, consultez la section [Configuration rapide avec aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) du Guide de l’utilisateur de l’interface de la ligne de commande AWS.
## Procédure
1. Récupérez l’URL OIDC de votre cluster Amazon EKS à l’aide de la CLI AWS.
```
$ aws eks describe-cluster --name my-cluster --query 'cluster.identity.oidc.issuer'
"https://oidc.eks.us-west-2.amazonaws.com/id/8EBDXXXX00BAE"
```
1. Récupérez la clé de signature publique à l’aide de curl ou d’un outil similaire. Le résultat est un [ensemble de clés web JSON (JWKS](https://www.rfc-editor.org/rfc/rfc7517#section-5)).
**Important**
Amazon EKS limite les appels vers le point de terminaison OIDC. Vous devez mettre en cache la clé de signature publique. Respectez l’en-tête `cache-control` inclus dans la réponse.
**Important**
Amazon EKS fait pivoter la clé de signature OIDC tous les sept jours.
```
$ curl https://oidc.eks.us-west-2.amazonaws.com/id/8EBDXXXX00BAE/keys
{"keys":[{"kty":"RSA","kid":"2284XXXX4a40","use":"sig","alg":"RS256","n":"wklbXXXXMVfQ","e":"AQAB"}]}
```
# Découvrir comment l’identité du pod Amazon EKS accorde aux pods l’accès aux services AWS
Les applications dans les conteneurs d’un Pod peuvent utiliser un SDK AWS ou l’interface CLI AWS pour envoyer des requêtes API aux services AWS à l’aide des autorisations de la gestion des identités et des accès AWS (IAM). Les applications doivent signer leurs demandes d’API AWS avec les informations d’identification AWS.
Les *identités du pod EKS* permettent de gérer les informations d’identification de vos applications, de la même manière que les profils d’instance Amazon EC2 fournissent des informations d’identification aux instances Amazon EC2. Au lieu de créer et distribuer vos informations d’identification AWS aux conteneurs ou d’utiliser le rôle de l’instance Amazon EC2, vous associez un rôle IAM à un compte de service Kubernetes et vous configurez vos pods pour qu’ils utilisent le compte de service.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/aUjJSorBE70?rel=0)
Chaque identité du pod EKS mappe un rôle à un compte de service dans un espace de noms dans le cluster spécifié. Si vous avez la même application dans plusieurs clusters, vous pouvez faire des associations identiques dans chaque cluster sans modifier la politique d’approbation du rôle.
Si un pod utilise un compte de service qui a une association, Amazon EKS définit des variables d’environnement dans les conteneurs du pod. Les variables d’environnement configurent les kits SDK AWS, y compris l’AWS CLI, pour utiliser les informations d’identification d’identité du pod EKS.
## Avantages des identités du pod EKS
Les identités du pod EKS offrent les avantages 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 au [service de métadonnées d’instance (IMDS) Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) est restreint, les conteneurs d’un pod ne peuvent récupérer que les informations d’identification du 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 accès à IMDS, mais les kits SDK et l’AWS CLI utiliseront les informations d’identification du pod lorsque celles-ci seront activées.
+ **Auditabilité** : l’accès et la journalisation des événements sont disponibles via AWS CloudTrail afin de faciliter l’audit rétrospectif.
**Important**
Les conteneurs ne constituent pas une frontière de sécurité, et l’utilisation de l’identité du pod 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.
L’identité du pod EKS est une méthode plus simple que [Rôles IAM pour les comptes de service](iam-roles-for-service-accounts.md), car elle n’utilise pas de fournisseurs d’identité OIDC. L’identité du pod EKS présente les améliorations suivantes :
+ **Opérations indépendantes** : dans de nombreuses organisations, la création de fournisseurs d’identité OIDC relève de la responsabilité d’équipes différentes de celles qui administrent les clusters Kubernetes. L’identité du pod EKS présente une séparation nette des tâches, où toute la configuration des associations de l’identité du pod EKS est effectuée dans Amazon EKS et toute la configuration des autorisations IAM est effectuée dans IAM.
+ **Réutilisabilité** : l’identité du pod EKS utilise un seul principal IAM au lieu des principaux distincts pour chaque cluster que les rôles IAM des comptes de service utilisent. Votre administrateur IAM ajoute le principal suivant à la politique d’approbation de n’importe quel rôle pour le rendre utilisable par les identités du pod EKS.
```
"Principal": {
"Service": "pods.eks.amazonaws.com"
}
```
+ **Capacité de mise à l’échelle** : chaque ensemble d’informations d’identification temporaires est pris en charge par le service d’authentification EKS dans l’identité du pod EKS, au lieu de chaque kit SDK AWS que vous exécutez dans chaque pod. Ensuite, l’agent de l’identité du pod Amazon EKS qui s’exécute sur chaque nœud émet les informations d’identification aux kits SDK. La charge est ainsi réduite à une seule fois pour chaque nœud et n’est pas dupliquée dans chaque pod. Pour plus de détails sur le processus, consultez [Comprendre le fonctionnement de l’identité du pod Amazon EKS](pod-id-how-it-works.md).
Pour plus d’informations sur la comparaison des deux solutions, consultez [Accorder aux charges de travail Kubernetes l’accès à AWS à l’aide des comptes de service Kubernetes](service-accounts.md).
## Présentation de la configuration des identités du pod EKS
Activez les identités du pod EKS en effectuant les procédures suivantes :
1. [Configurer l’agent de l’identité du pod Amazon EKS](pod-id-agent-setup.md) : vous n’effectuez cette procédure qu’une seule fois pour chaque cluster. Vous n’avez pas besoin d’effectuer cette étape si le mode automatique EKS est activé sur votre cluster.
1. [Attribuer un rôle IAM à un compte de service Kubernetes](pod-id-association.md) : effectuez cette procédure pour chaque ensemble unique d’autorisations que vous voulez attribuer à une application.
1. [Configurer les pods pour accéder aux AWS services avec des comptes de service](pod-id-configure-pods.md) : effectuez cette procédure pour chaque pod qui doit accéder aux services AWS.
1. [Utiliser l’identité du pod avec le SDK AWS](pod-id-minimum-sdk.md) : vérifiez que la charge de travail utilise un kit SDK AWS d’une version prise en charge et qu’elle utilise la chaîne d’informations d’identification par défaut.
## Limites
+ Jusqu’à 5 000 associations d’identité du pod EKS par cluster sont prises en charge pour mapper les rôles IAM aux comptes de service Kubernetes.
## Considérations
+ **Association de rôles IAM** : chaque compte de service Kubernetes d’un cluster peut être associé à un rôle IAM du même compte AWS que le cluster. Pour modifier le rôle, modifiez l’association d’identité du pod EKS. Pour l’accès intercompte, déléguez l’accès au rôle à l’aide des rôles IAM. Pour en savoir plus, consultez [Déléguer l’accès entre les comptes AWS à l’aide des rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html) dans le *Guide de l’utilisateur IAM*.
+ **Agent d’identité du pod EKS** : l’agent d’identité du pod est nécessaire pour utiliser l’identité du pod EKS. L’agent s’exécute en tant que `DaemonSet` Kubernetes sur les nœuds du cluster, fournissant des informations d’identification uniquement aux pods du même nœud. Il utilise le `hostNetwork` du nœud, occupant les ports `80` et `2703` sur l’adresse locale de liaison (`169.254.170.23` pour IPv4, `[fd00:ec2::23]` pour IPv6). Si IPv6 est désactivé dans votre cluster, désactivez IPv6 pour l’agent d’identité du pod EKS. Pour en savoir plus, consultez [Désactiver IPv6 dans l’agent d’identité du pod EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-config-ipv6.html).
+ **Cohérence à terme** : les associations d’identité du pod EKS sont cohérentes à terme, avec des retards potentiels de plusieurs secondes après les appels d’API. Évitez de créer ou de mettre à jour des associations dans des chemins de code critiques et à haute disponibilité. Effectuez plutôt ces actions dans des routines d’initialisation ou de configuration distinctes et moins fréquentes. Pour en savoir plus, consultez [Groupes de sécurité par pod](https://docs.aws.amazon.com/eks/latest/best-practices/sgpp.html) dans le *Guide des bonnes pratiques EKS*.
+ **Considérations relatives au proxy et au groupe de sécurité** : pour les pods utilisant un proxy, ajoutez `169.254.170.23` (IPv4) et `[fd00:ec2::23]` (IPv6) aux variables d’environnement `no_proxy/NO_PROXY` afin d’éviter les échecs de demandes vers l’agent d’identité du pod EKS. Si vous utilisez des groupes de sécurité pour les pods avec le CNI VPC AWS, définissez l’indicateur `ENABLE_POD_ENI` sur « true » et l’indicateur `POD_SECURITY_GROUP_ENFORCING_MODE` sur « standard ». Pour en savoir plus, consultez [Attribuer des groupes de sécurité à des pods individuels](https://docs.aws.amazon.com/eks/latest/userguide/security-groups-for-pods.html).
### Versions du cluster de l’identité du pod EKS
Pour utiliser l’identité du pod EKS, le cluster doit disposer d’une version de plateforme identique ou supérieure à celle indiquée dans le tableau suivant, ou d’une version Kubernetes supérieure à celles indiquées dans le tableau. Pour connaître la version recommandée de l’Agent de l’identité du pod Amazon EKS pour une version Kubernetes, consultez [Vérification de la compatibilité de la version du module complémentaire Amazon EKS avec un cluster](addon-compat.md).
| Version de Kubernetes | Version de la plateforme |
| --- | --- |
| Versions Kubernetes non répertoriées | Toutes les versions de plateforme prennent en charge |
| `1.28` | `eks.4` |
### Restrictions relatives à l’identité du pod EKS
Les identités du pod EKS sont disponibles sur les éléments suivants :
+ Les versions du cluster Amazon EKS répertoriées dans la rubrique précédente [Versions du cluster de l’identité du pod EKS](#pod-id-cluster-versions).
+ Les composants master du cluster qui sont des instances Amazon EC2 Linux.
Les identités du pod Amazon EKS ne sont pas disponibles dans les cas suivants :
+ AWS Outposts.
+ Amazon EKS Anywhere.
+ Clusters Kubernetes que vous créez et exécutez sur Amazon EC2. Les composants de l’identité du pod Amazon EKS sont uniquement disponibles sur Amazon EKS.
Vous ne pouvez pas utiliser les identités du pod Amazon EKS avec :
+ Les pods qui s’exécutent n’importe où, à l’exception des instances Amazon EC2 Linux. Les pods Linux et Windows qui s’exécutent sur AWS Fargate (Fargate) ne sont pas pris en charge. Les pods qui s’exécutent sur des instances Amazon EC2 Windows ne sont pas pris en charge.
# Comprendre le fonctionnement de l’identité du pod Amazon EKS
Les associations de l’identité du pod Amazon EKS offrent une capacité de gestion des informations d’identification à utiliser pour les applications, de la même façon que les profils d’instance Amazon EC2 fournissent des informations d’identification aux instances EC2.
L’identité du pod Amazon EKS fournit des informations d’identification à vos charges de travail avec une API d’*authentification EKS* supplémentaire et un pod d’agent qui s’exécute sur chaque nœud.
Dans vos modules complémentaires, tels que les *modules complémentaires Amazon EKS* et le contrôleur autogéré, les opérateurs et autres modules complémentaires, l’auteur doit mettre à jour son logiciel pour utiliser les derniers kits SDK AWS. Pour la liste de compatibilité entre l’identité du pod EKS et les modules complémentaires produits par Amazon EKS, reportez-vous à la section précédente [Restrictions relatives à l’identité du pod EKS](pod-identities.md#pod-id-restrictions).
## Utilisation des identités du pod EKS dans votre code
Dans votre code, vous pouvez utiliser les kits SDK AWS pour accéder aux services AWS. Vous écrivez du code pour créer un client pour un service AWS avec un kit SDK, et par défaut, le kit SDK recherche dans une chaîne d’emplacements les informations d’identification de la gestion des identités et des accès AWS à utiliser. Une fois les informations d’identification valides trouvées, la recherche s’arrête. Pour plus d’informations sur les emplacements par défaut utilisés, consultez [Chaîne de fournisseurs d’informations d’identification](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain) dans le Guide de référence des kits SDK et des outils AWS.
Les identités du pod EKS ont été ajoutées au *fournisseur d’informations d’identification du conteneur* qui est recherché dans une étape de la chaîne d’informations d’identification par défaut. Si vos charges de travail utilisent actuellement des informations d’identification antérieures dans la chaîne de fournisseurs d’informations d’identification, ces informations continueront d’être utilisées même si vous configurez une association d’identité du pod EKS pour la même charge de travail. Ainsi, vous pouvez migrer en toute sécurité à partir d’autres types d’informations d’identification en créant d’abord l’association, avant de supprimer les anciennes informations d’identification.
Le fournisseur d’informations d’identification de conteneur fournit des informations d’identification temporaires à partir d’un agent qui s’exécute sur chaque nœud. Dans Amazon EKS, l’agent est l’agent d’identité du pod Amazon EKS et sur Amazon Elastic Container Service, l’agent est le `amazon-ecs-agent`. Les kits SDK utilisent des variables d’environnement pour localiser l’agent auquel se connecter.
En revanche, les *rôles IAM pour les comptes de service* fournissent un jeton d’*identité Web * que le kit SDK AWS doit échanger avec le service de jetons de sécurité AWS à l’aide d’`AssumeRoleWithWebIdentity`.
## Fonctionnement de l’agent de l’identité du pod EKS avec un pod
1. Lorsque Amazon EKS démarre un nouveau pod qui utilise un compte de service associé à une identité du pod EKS, le cluster ajoute le contenu suivant au manifeste du pod :
```
env:
- name: AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE
value: "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token"
- name: AWS_CONTAINER_CREDENTIALS_FULL_URI
value: "http://169.254.170.23/v1/credentials"
volumeMounts:
- mountPath: "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/"
name: eks-pod-identity-token
volumes:
- name: eks-pod-identity-token
projected:
defaultMode: 420
sources:
- serviceAccountToken:
audience: pods.eks.amazonaws.com
expirationSeconds: 86400 # 24 hours
path: eks-pod-identity-token
```
1. Kubernetes sélectionne le nœud sur lequel exécuter le pod. Ensuite, l’agent d’identité du pod Amazon EKS sur le nœud utilise l’action [AssumeRoleForPodIdentity](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html) pour récupérer des informations d’identification temporaires auprès de l’API d’authentification EKS.
1. L’agent d’identité du pod EKS met ces identités à la disposition des kits SDK AWS que vous exécutez à l’intérieur de vos conteneurs.
1. Vous utilisez le kit SDK dans votre application sans spécifier de fournisseur d’informations d’identification pour utiliser la chaîne d’informations d’identification par défaut. Vous pouvez également spécifier le fournisseur d’informations d’identification du conteneur. Pour plus d’informations sur les emplacements par défaut utilisés, consultez [Chaîne de fournisseurs d’informations d’identification](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain) dans le Guide de référence des kits SDK et des outils AWS.
1. Le kit SDK utilise les variables d’environnement pour se connecter à l’agent d’identité du pod EKS et récupérer les informations d’identification.
**Note**
Si vos charges de travail utilisent actuellement des informations d’identification antérieures dans la chaîne de fournisseurs d’informations d’identification, ces informations continueront d’être utilisées même si vous configurez une association d’identité du pod EKS pour la même charge de travail.
# Configurer l’agent de l’identité du pod Amazon EKS
Les associations Amazon EKS Pod Identity 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 EC2 instances Amazon.
L’identité du pod Amazon EKS fournit des informations d’identification à vos charges de travail avec une API d’*authentification EKS* supplémentaire et un pod d’agent qui s’exécute sur chaque nœud.
**Astuce**
Vous n’avez pas besoin d’installer l’agent de l’identité du pod Amazon EKS sur les clusters du mode automatique EKS. Cette fonctionnalité est créée dans le mode automatique EKS.
## Considérations
+ Par défaut, l’agent de l’identité du pod Amazon EKS est préinstallé sur les clusters du mode automatique EKS. Pour en savoir plus, veuillez consulter la section [Automatisation de l’infrastructure du cluster avec le mode automatique EKS](automode.md).
+ Par défaut, l’agent d’identité du pod EKS écoute sur une adresse `IPv4` et `IPv6` pour que les pods puissent demander des informations d’identification. L’agent utilise l’adresse IP de bouclage (localhost) `169.254.170.23` pour `IPv4` et l’adresse IP localhost `[fd00:ec2::23]` pour `IPv6`.
+ Si vous désactivez les adresses `IPv6` ou empêchez d’une autre manière les adresses IP `IPv6` localhost, l’agent ne peut pas démarrer. Pour démarrer l’agent sur des nœuds qui ne peuvent pas utiliser `IPv6`, suivez les étapes décrites dans [Désactiver `IPv6` dans l’agent d’identité du pod EKS](pod-id-agent-config-ipv6.md) pour désactiver la configuration `IPv6`.
## Création d’un agent d’identité du pod Amazon EKS
### Conditions préalables pour l’agent
+ Un cluster Amazon EKS existant. Pour en déployer un, consultez [Mise en route avec Amazon EKS](getting-started.md). La version du cluster et la version de plateforme doivent être identiques ou supérieures aux versions répertoriées dans [Versions du cluster de l’identité du pod EKS](pod-identities.md#pod-id-cluster-versions).
+ Le rôle de nœud dispose d’autorisations permettant à l’agent d’effectuer l’action `AssumeRoleForPodIdentity` dans l’API d’authentification EKS. Vous pouvez utiliser la [politique AWS gérée : Amazon EKSWorker NodePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksworkernodepolicy) ou ajouter une politique personnalisée similaire à la suivante :
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks-auth:AssumeRoleForPodIdentity"
],
"Resource": "*"
}
]
}
```
Cette action peut être limitée par des balises pour restreindre les rôles qui peuvent être assumés par les pods qui utilisent l’agent.
+ Les nœuds peuvent atteindre et télécharger des images à partir d’Amazon ECR. L’image de conteneur pour le module complémentaire se trouve dans les registres répertoriés dans [Afficher les registres d’images de conteneur Amazon pour les modules complémentaires Amazon EKS](add-ons-images.md).
Notez que vous pouvez modifier l'emplacement de l'image et `imagePullSecrets` prévoir des modules complémentaires EKS dans les **paramètres de configuration facultatifs** de et `--configuration-values` dans la AWS CLI. AWS Management Console
+ Les nœuds peuvent accéder à l’API d’authentification Amazon EKS. Pour les clusters privés, le `eks-auth` point de terminaison AWS PrivateLink est obligatoire.
### Agent d'installation avec AWS console
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dans le panneau de navigation de gauche, sélectionnez **Clusters**, puis sélectionnez le nom du cluster pour lequel vous souhaitez configurer le module complémentaire l’agent d’identité du pod EKS.
1. Choisissez l’onglet **Modules complémentaires**.
1. Choisissez **Obtenez plus de modules complémentaires**.
1. Cochez la case en haut à droite du module complémentaire de l’agent d’identité du pod EKS, puis sélectionnez **Suivant**.
1. Sur la page **Configurer les paramètres de modules complémentaires sélectionnés**, sélectionnez n’importe quelle **Version** dans la liste déroulante Version.
1. (Facultatif) Développez les **Paramètres de configuration facultatifs** pour entrer une configuration supplémentaire. Par exemple, vous pouvez fournir un autre emplacement d’image de conteneur et `ImagePullSecrets`. Le schéma JSON avec les clés acceptées est présenté dans **Schéma de configuration du module complémentaire**.
Saisissez les clés et les valeurs de configuration dans **Valeurs de configuration**.
1. Choisissez **Suivant**.
1. Confirmez que les pods de l’agent d’identité du pod EKS sont en cours d’exécution sur votre cluster.
```
kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'
```
L'exemple qui suit illustre un résultat.
```
eks-pod-identity-agent-gmqp7 1/1 Running 1 (24h ago) 24h
eks-pod-identity-agent-prnsh 1/1 Running 1 (24h ago) 24h
```
Vous pouvez maintenant utiliser les associations d’identité du pod EKS dans votre cluster. Pour de plus amples informations, veuillez consulter [Attribuer un rôle IAM à un compte de service Kubernetes](pod-id-association.md).
### Agent de configuration avec AWS CLI
1. Exécutez la commande AWS CLI suivante. Remplacez `my-cluster` par le nom de votre cluster.
```
aws eks create-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent --addon-version v1.0.0-eksbuild.1
```
**Note**
L’agent de l’identité du pod Amazon EKS n’utilise pas le `service-account-role-arn` pour les *rôles IAM pour les comptes de service*. Vous devez fournir à l’agent d’identité du pod EKS des autorisations dans le rôle de nœud.
1. Confirmez que les pods de l’agent d’identité du pod EKS sont en cours d’exécution sur votre cluster.
```
kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'
```
L'exemple qui suit illustre un résultat.
```
eks-pod-identity-agent-gmqp7 1/1 Running 1 (24h ago) 24h
eks-pod-identity-agent-prnsh 1/1 Running 1 (24h ago) 24h
```
Vous pouvez maintenant utiliser les associations d’identité du pod EKS dans votre cluster. Pour de plus amples informations, veuillez consulter [Attribuer un rôle IAM à un compte de service Kubernetes](pod-id-association.md).
# Attribuer un rôle IAM à un compte de service Kubernetes
Cette rubrique explique comment configurer un compte de service Kubernetes pour qu'il assume un rôle de gestion des AWS identités et des accès (IAM) avec EKS Pod Identity. 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.
Pour créer une association EKS Pod Identity, il n'y a qu'une seule étape : vous créez l'association dans EKS via la AWS Management Console AWS CLI AWS CloudFormation et d'autres outils. AWS SDKs Il n’y a aucune donnée ou métadonnée concernant les associations à l’intérieur du cluster dans les objets Kubernetes et vous n’ajoutez aucune annotation aux comptes de service.
**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).
+ Le principal IAM qui crée l’association doit avoir le `iam:PassRole`.
+ La dernière version de la AWS CLI installée et configurée sur votre appareil ou AWS CloudShell. Vous pouvez vérifier votre version actuelle avec `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 dans le 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).
## Création d'une association Pod Identity (AWS console)
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dans le panneau de navigation de gauche, sélectionnez **Clusters**, puis sélectionnez le nom du cluster pour lequel vous souhaitez configurer le module complémentaire l’agent d’identité du pod EKS.
1. Choisissez l’onglet **Access**.
1. Dans **Associations d’identité du pod**, sélectionnez **Créer**.
1. Pour **Rôle IAM**, sélectionnez le rôle IAM avec les autorisations dont a besoin la charge de travail.
**Note**
La liste ne contient que les rôles qui ont la politique d’approbation suivante qui permet à l’identité du pod EKS de les utiliser.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
`sts:AssumeRole` : l’identité du pod EKS utilise `AssumeRole` pour assumer le rôle IAM avant de transmettre les informations d’identification temporaires à vos pods.
`sts:TagSession`— EKS Pod Identity est utilisé `TagSession` pour inclure des *balises de session* dans les demandes adressées à AWS STS.
Vous pouvez utiliser ces balises dans les *clés de condition* de la politique d’approbation pour restreindre les comptes de service, les espaces de noms et les clusters pouvant utiliser ce rôle.
Pour obtenir la liste des clés de condition Amazon EKS, consultez la rubrique [Conditions définies par Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys) de la *Référence de l'autorisation de service*. Pour savoir avec quelles actions et ressources vous pouvez utiliser une clé de condition, consultez la rubrique [Actions définies par Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions).
1. Pour l’**espace de noms Kubernetes**, sélectionnez l’espace de noms Kubernetes qui contient le compte de service et la charge de travail. Vous pouvez également spécifier un espace de noms par son nom qui n’existe pas dans le cluster.
1. Pour le **compte de service Kubernetes**, sélectionnez le compte de service Kubernetes à utiliser. Le manifeste de votre charge de travail Kubernetes doit spécifier ce compte de service. Vous pouvez également spécifier un compte de service par son nom qui n’existe pas dans le cluster.
1. (Facultatif) Sélectionnez **Désactiver les balises de session** pour désactiver les balises de session par défaut que Pod Identity ajoute automatiquement lorsqu'il assume le rôle.
1. (Facultatif) Activez l'option **Configurer la politique de session** pour configurer une politique IAM afin d'appliquer des restrictions supplémentaires à cette association Pod Identity au-delà des autorisations définies dans la stratégie IAM attachée au rôle IAM.
**Note**
Une politique de session ne peut être appliquée que lorsque le paramètre **Désactiver les balises de session** est coché.
1. (Facultatif) Pour **Balises**, choisissez **Ajouter une balise** pour ajouter des métadonnées dans une paire clé et valeur. Ces balises sont appliquées à l’association et peuvent être utilisées dans les politiques IAM.
Vous pouvez répéter cette étape pour ajouter plusieurs balises.
1. Choisissez **Créer**.
## Création d'une association Pod Identity (AWS CLI)
1. Si vous souhaitez associer une politique IAM existante à votre rôle IAM, passez à l'étape suivante.
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
```
1. Créez un rôle IAM, puis associez-le à un compte de service Kubernetes.
1. Si vous avez déjà un compte de service Kubernetes devant assumer un rôle IAM, vous pouvez ignorer cette étape.
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 <
1. Vérifiez que la stratégie d’approbation du rôle IAM est correctement configurée.
```
aws iam get-role --role-name my-role --query Role.AssumeRolePolicyDocument
```
L'exemple qui suit illustre un résultat.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Allow EKS Auth service to assume this role for Pod Identities",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
1. Vérifiez que la stratégie que vous avez associée à votre rôle lors d'une étape précédente est associée au rôle.
```
aws iam list-attached-role-policies --role-name my-role --query 'AttachedPolicies[].PolicyArn' --output text
```
L'exemple qui suit illustre un résultat.
```
arn:aws: iam::111122223333:policy/my-policy
```
1. Définissez une variable pour stocker l'Amazon Resource Name (ARN) de la stratégie que vous souhaitez utiliser. *my-policy*Remplacez-le par le nom de la politique pour laquelle vous souhaitez confirmer les autorisations.
```
export policy_arn=arn:aws: iam::111122223333:policy/my-policy
```
1. Affichez la version par défaut de la stratégie.
```
aws iam get-policy --policy-arn $policy_arn
```
L'exemple qui suit illustre un résultat.
```
{
"Policy": {
"PolicyName": "my-policy",
"PolicyId": "EXAMPLEBIOWGLDEXAMPLE",
"Arn": "arn:aws: iam::111122223333:policy/my-policy",
"Path": "/",
"DefaultVersionId": "v1",
[...]
}
}
```
1. Consultez le contenu de la stratégie pour vous assurer qu’elle inclut toutes les autorisations nécessaires pour votre pod. Si nécessaire, remplacez *1* la commande suivante par la version renvoyée dans la sortie précédente.
```
aws iam get-policy-version --policy-arn $policy_arn --version-id v1
```
L'exemple qui suit illustre un résultat.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-pod-secrets-bucket"
}
]
}
```
Si vous avez créé l'exemple de stratégie lors d'une étape précédente, le résultat est le même. Si vous avez créé une politique différente, le *example* contenu est différent.
## Étapes suivantes
[Configurer les pods pour accéder aux AWS services avec des comptes de service](pod-id-configure-pods.md)
# Accédez aux AWS ressources à l'aide des rôles IAM EKS Pod Identity Target
Lorsque vous exécutez des applications sur Amazon Elastic Kubernetes Service (Amazon EKS), il se peut que vous deviez accéder AWS à des ressources qui existent dans différents comptes. AWS Ce guide explique comment configurer l'accès entre comptes à l'aide d'EKS Pod Identity, qui permet à vos pods Kubernetes d'accéder à d'autres AWS ressources à l'aide de rôles cibles.
## Conditions préalables
Avant de commencer, assurez-vous d’avoir effectué les étapes suivantes :
+ [Configurer l’agent de l’identité du pod Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html)
+ [Créer un rôle identité du pod EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)
## Comment ça marche
Pod Identity permet aux applications de votre cluster EKS d'accéder aux AWS ressources de différents comptes par le biais d'un processus appelé chaînage des rôles.
Lorsque vous créez une association Pod Identity, vous pouvez fournir deux rôles IAM : un [rôle EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) dans le même compte que votre cluster EKS et un rôle IAM cible provenant du compte contenant les AWS ressources auxquelles vous souhaitez accéder (comme les compartiments S3 ou les bases de données RDS). Le [rôle EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) doit figurer dans le compte de votre cluster EKS en raison des PassRole exigences [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam-passrole-service.html), tandis que le rôle IAM cible peut se trouver dans n'importe quel AWS compte. PassRole permet à une AWS entité de déléguer l'attribution de rôles à un autre service. EKS Pod Identity PassRole permet de connecter un rôle à un compte de service Kubernetes, ce qui nécessite que le rôle et l'identité qui le transmettent se trouvent dans le même AWS compte que le cluster EKS. Lorsque votre pod d'application a besoin d'accéder à AWS des ressources, il demande des informations d'identification à Pod Identity. L’identité du pod effectue alors automatiquement deux prises de rôle consécutives : elle prend d’abord le [rôle d’identité du pod EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html), puis utilise ces informations d’identification pour prendre le rôle IAM cible. Ce processus fournit à votre pod des informations d'identification temporaires dotées des autorisations définies dans le rôle cible, ce qui permet un accès sécurisé aux ressources d'autres AWS comptes.
## Considérations relatives à la mise en cache
En raison des mécanismes de mise en cache, les mises à jour d’un rôle IAM dans une association identité du pod EKS peuvent ne pas prendre effet immédiatement dans les pods s’exécutant sur votre cluster EKS. L’agent identité du pod met en cache les informations d’identification IAM en fonction de la configuration de l’association au moment où les informations d’identification sont récupérées. Si l’association comprend uniquement un [rôle d’identité du pod EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) et aucun rôle IAM cible, les informations d’identification mises en cache sont valables pendant 6 heurs. Si l’association comprend à la fois l’ARN du [rôle d’identité du pod EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) et un rôle IAM cible, les informations d’identification mises en cache sont valables pendant 59 minutes. La modification d’une association existante, telle que la mise à jour de l’ARN du [rôle d’identité du pod EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) ou l’ajout d’un rôle IAM cible, ne réinitialise pas le cache existant. Par conséquent, l’agent ne reconnaîtra pas les mises à jour tant que les informations d’identification mises en cache n’auront pas été actualisées. Pour appliquer les modifications plus rapidement, vous pouvez recréer les pods existants ; sinon, vous devrez attendre l’expiration du cache.
## Étape 1 : créer et associer un rôle IAM cible
Au cours de cette étape, vous allez établir une chaîne de confiance sécurisée en créant et en configurant un rôle IAM cible. À titre de démonstration, nous allons créer un nouveau rôle IAM cible pour établir une chaîne de confiance entre deux AWS comptes : le [rôle EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) (par exemple`eks-pod-identity-primary-role`) du AWS compte du cluster EKS est autorisé à assumer le rôle IAM cible (par exemple`eks-pod-identity-aws-resources`) sur votre compte cible, permettant ainsi d'accéder à des AWS ressources telles que les compartiments Amazon S3.
### Créer le rôle IAM cible
1. Ouvrez la [console Amazon IAM](https://console.aws.amazon.com/iam/home).
1. Dans la barre de navigation supérieure, vérifiez que vous êtes connecté au compte contenant les AWS ressources (telles que des compartiments S3 ou des tables DynamoDB) pour votre rôle IAM cible.
1. Dans le volet de navigation de gauche, choisissez **Rôles**.
1. Cliquez sur le bouton **Créer un rôle**, puis sur le ** AWS compte** sous « Type d'entité fiable ».
1. Choisissez **Un autre AWS compte**, entrez votre numéro de AWS compte (le compte sur lequel se trouve votre [rôle EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)), puis choisissez **Next**.
1. **Ajoutez les politiques d'autorisation que vous souhaitez associer au rôle (par exemple, AmazonS3FullAccess), puis choisissez Next.**
1. Saisissez un nom de rôle, tel que `MyCustomIAMTargetRole`, puis sélectionnez **Créer un rôle**.
### Mettre à jour la politique d’approbation du rôle IAM cible
1. Après avoir créé le rôle, vous serez redirigé vers la liste **Rôles**. Recherchez et sélectionnez le nouveau rôle que vous avez créé à l’étape précédente (par exemple, `MyCustomIAMTargetRole`).
1. Sélectionnez l’onglet **Relations d’approbation**.
1. Cliquez sur **Modifier la politique d’approbation** à droite.
1. Dans l’éditeur de politique, remplacez le JSON par défaut par votre politique d’approbation. Remplacez les valeurs d'espace réservé pour le nom du rôle et `111122223333` dans l'ARN du rôle IAM par l'ID du AWS compte hébergeant votre cluster EKS. Vous pouvez également éventuellement utiliser la politique de confiance PrincipalTags dans les rôles pour autoriser uniquement des comptes de service spécifiques d'un cluster et d'un espace de noms donnés à assumer votre rôle cible. Par exemple :
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/eks-cluster-arn": "arn:aws:eks:us-east-1:111122223333:cluster/example-cluster",
"aws:RequestTag/kubernetes-namespace": "ExampleNameSpace",
"aws:RequestTag/kubernetes-service-account": "ExampleServiceAccountName"
},
"ArnEquals": {
"aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role"
}
}
}
]
}
```
La politique ci-dessus permet au rôle `eks-pod-identeity-primary-role` du AWS compte 111122223333 doté des [tags de session EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html) appropriés d'assumer ce rôle.
Si vous avez [désactivé les balises de session](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html#pod-id-abac-tags) dans votre identité du pod EKS, l’identité du pod EKS définit également le `sts:ExternalId` avec des informations sur le cluster, l’espace de noms et le compte de service d’un pod lors de l’assomption d’un rôle cible.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "region/111122223333/cluster-name/namespace/service-account-name"
},
"ArnEquals": {
"aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role"
}
}
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:TagSession"
}
]
}
```
La politique ci-dessus permet de garantir que seuls le cluster, l’espace de noms et le compte de service attendus peuvent assumer le rôle cible.
### Mettre à jour la politique d’autorisation pour le rôle d’identité du pod EKS
Au cours de cette étape, vous allez mettre à jour la politique d’autorisation du [rôle d’identité du pod EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) associé à votre cluster Amazon EKS en ajoutant l’ARN du rôle IAM cible en tant que ressource.
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dans le volet de navigation gauche, sélectionnez **Clusters**, puis sélectionnez le nom de votre cluster EKS.
1. Choisissez l’onglet **Access**.
1. Sous **Associations d’identité du pod**, sélectionnez votre [rôle d’identité du pod EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html).
1. Sélectionnez **Autorisations**, **Ajouter des autorisations**, puis **Créer une politique en ligne**.
1. Sélectionnez **JSON** sur le côté droit.
1. Dans l’éditeur de politique, remplacez le JSON par défaut par votre politique d’autorisation. Remplacez la valeur de remplacement pour le nom du rôle et `222233334444` dans l’ARN du rôle IAM par votre rôle IAM cible. Par exemple :
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Resource": "arn:aws:iam::222233334444:role/eks-pod-identity-aws-resources"
}
]
}
```
## Étape 2 : associer le rôle IAM cible à un compte de service Kubernetes
Au cours de cette étape, vous allez créer une association entre le rôle IAM cible et le compte de service Kubernetes dans votre cluster EKS.
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dans le panneau de navigation gauche, sélectionnez **Clusters**, puis le nom du cluster auquel vous voulez ajouter l’association.
1. Choisissez l’onglet **Access**.
1. Dans **Associations d’identité du pod**, sélectionnez **Créer**.
1. Sélectionnez le [Rôle d’identité du pod EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) dans **Rôle IAM** pour vos charges de travail.
1. Sélectionnez le rôle IAM cible dans **Rôle IAM cible** qui sera assumé par le [Rôle d’identité du pod EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html).
1. Dans le champ **Espace de noms Kubernetes**, saisissez le nom de l’espace de noms dans lequel vous voulez créer l’association (par exemple, `my-app-namespace`). Cela permet de définir l’emplacement du compte de service.
1. Dans le champ **Compte de service Kubernetes**, saisissez le nom du compte de service (par exemple, `my-service-account`) qui utilisera les informations d’identification IAM. Cela permet de lier le rôle IAM au compte de service.
1. (Facultatif) Sélectionnez **Désactiver les balises de session** pour désactiver les balises de session par défaut que Pod Identity ajoute automatiquement lorsqu'il assume le rôle.
1. (Facultatif) Activez l'option **Configurer la politique de session** pour configurer une politique IAM afin d'appliquer des restrictions supplémentaires à cette association Pod Identity au-delà des autorisations définies dans la stratégie IAM attachée au rôle IAM **cible**.
**Note**
1. Une politique de session ne peut être appliquée que lorsque le paramètre **Désactiver les balises de session** est coché. 2. Si vous spécifiez une politique de session, les restrictions de politique s'appliquent aux autorisations du **rôle Target IAM** et non au **rôle IAM** associé à cette association Pod Identity.
1. Sélectionnez **Créer** pour créer l’association.
# Configurer les pods pour accéder aux AWS services avec des comptes de service
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 compte de service Kubernetes existant et une association d’identité du pod EKS qui associe le compte de service à un 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 [Attribuer un rôle IAM à un compte de service Kubernetes](pod-id-association.md).
+ La dernière version de la AWS CLI installée et configurée sur votre appareil ou AWS CloudShell. Vous pouvez vérifier votre version actuelle avec `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 dans le 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 <
Le contrôle d’accès par attributs (ABAC) accorde des droits aux utilisateurs grâce à des politiques qui combinent des attributs. L’identité du pod EKS associe des balises aux informations d’identification temporaires de chaque pod avec des attributs tels que le nom du cluster, l’espace de noms et le nom du compte de service. Ces balises de session de rôle permettent aux administrateurs de créer un rôle unique qui peut fonctionner avec tous les comptes de service en autorisant l'accès aux AWS ressources en fonction des balises correspondantes. En ajoutant la prise en charge des balises de session de rôle, vous pouvez renforcer la sécurité entre les clusters et les charges de travail au sein des clusters, tout en réutilisant les mêmes rôles et politiques IAM.
## Exemple de politique avec balises
Vous trouverez ci-dessous un exemple de politique IAM qui accorde les autorisations `s3:GetObject` lorsque l’objet correspondant est balisé avec le nom du cluster EKS.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:GetObjectTagging"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"s3:ExistingObjectTag/eks-cluster-name": "${aws:PrincipalTag/eks-cluster-name}"
}
}
}
]
}
```
## Activer ou désactiver les balises de session
Lorsqu’il assume le rôle, l’identité du pod EKS ajoute un ensemble prédéfini de balises de session. Ces balises de session permettent aux administrateurs de créer un rôle unique qui peut fonctionner avec toutes les ressources en autorisant l'accès aux AWS ressources en fonction des balises correspondantes.
### Activer les balises de session
Les balises de session sont automatiquement activées avec l’identité du pod EKS. Aucune action n’est requise de votre part. Par défaut, l’identité du pod EKS associe un ensemble de balises prédéfinies à votre session. Pour référencer ces balises dans les politiques, utilisez la syntaxe `${aws:PrincipalTag/` suivie de la clé de balise. Par exemple, `${aws:PrincipalTag/kubernetes-namespace}`.
+ `eks-cluster-arn`
+ `eks-cluster-name`
+ `kubernetes-namespace`
+ `kubernetes-service-account`
+ `kubernetes-pod-name`
+ `kubernetes-pod-uid`
### Désactivation des balises de session
AWS compresse les politiques de session intégrées, les politiques ARNs gérées et les balises de session dans un format binaire compressé doté d'une limite distincte. Si vous recevez une erreur `PackedPolicyTooLarge` indiquant que le format binaire compressé a dépassé la limite de taille, vous pouvez essayer de réduire la taille en désactivant les balises de session ajoutées par l’identité du pod EKS. Pour désactiver ces balises de session, veuillez suivre les étapes suivantes :
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dans le panneau de navigation gauche, sélectionnez **Clusters**, puis sélectionnez le nom du cluster que vous voulez modifier.
1. Choisissez l’onglet **Access**.
1. Dans **Associations d’identité du pod**, choisissez l’ID d’association que vous souhaitez modifier dans **ID d’association**, puis choisissez **Modifier**.
1. Sous **Balises de session**, choisissez **Désactiver les balises de session**.
1. Sélectionnez **Enregistrer les modifications**.
## Balises inter-comptes
Toutes les balises de session ajoutées par l’identité du pod EKS sont *transitives* ; les clés et les valeurs des balises sont transmises à toutes les actions `AssumeRole` que vos charges de travail utilisent pour changer de rôle dans un autre compte. Vous pouvez utiliser ces balises dans les politiques d’autres comptes pour limiter l’accès dans des scénarios intercomptes. Pour plus d’informations, consultez [Chaînage des rôles avec des balises de session](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html#id_session-tags_role-chaining) dans le *Guide de l’utilisateur IAM*.
## Balises personnalisées
L’identité du pod EKS ne peut pas ajouter de balises personnalisées supplémentaires à l’action `AssumeRole` qu’il effectue. Cependant, les balises que vous appliquez au rôle `${aws:PrincipalTag/` IAM sont toujours disponibles dans le même format : `${aws:PrincipalTag/MyCustomTag}` suivi de la clé, par exemple .
**Note**
Les balises ajoutées à la session via la demande `sts:AssumeRole` sont prioritaires en cas de conflit. Par exemple, supposons que :
Amazon EKS ajoute une clé `eks-cluster-name` et une valeur `my-cluster` à la session lorsque EKS assume le rôle client et
Vous ajoutez une balise `eks-cluster-name` au rôle IAM avec la valeur `my-own-cluster`.
Dans ce cas, la première a priorité et la valeur de la balise `eks-cluster-name` sera `my-cluster`.
# Utiliser l’identité du pod avec le SDK AWS
## Utilisation des informations d'identification de l'identité du pod EKS
Pour utiliser les informations d’identification d’une association d’identité du pod EKS, votre code peut utiliser n’importe quel kit SDK AWS pour créer un client pour un service AWS avec un kit SDK. Par défaut, le kit SDK recherche dans une chaîne d’emplacements les informations d’identification de la gestion des identités et des accès AWS à utiliser. Les informations d’identification d’identité du pod EKS seront utilisées si vous ne spécifiez pas de fournisseur d’informations d’identification lors de la création du client ou de l’initialisation du SDK.
Cela fonctionne parce que les identités du pod EKS ont été ajoutées au *fournisseur d'informations d'identification du conteneur* qui est recherché dans une étape de la chaîne d'informations d'identification par défaut. Si vos charges de travail utilisent actuellement des informations d'identification antérieures dans la chaîne de fournisseurs d'informations d'identification, ces informations continueront d'être utilisées même si vous configurez une association d'identité du pod EKS pour la même charge de travail.
Pour plus d'informations sur le fonctionnement des identités du pod EKS, consultez [Comprendre le fonctionnement de l’identité du pod Amazon EKS](pod-id-how-it-works.md).
Lorsque vous utilisez [Découvrez comment l’identité du pod EKS accorde aux pods l’accès aux services AWS](pod-identities.md), les conteneurs de vos pods doivent utiliser une version AWS du kit SDK qui prend en charge l’assumption d’un rôle IAM à partir de l’agent d’identité du pod EKS. Veillez à utiliser les versions suivantes, ou ultérieures, pour votre kit SDK AWS :
+ Java (version 2) : [2.21.30](https://github.com/aws/aws-sdk-java-v2/releases/tag/2.21.30)
+ Java : [1.12.746](https://github.com/aws/aws-sdk-java/releases/tag/1.12.746)
+ Go v1 : [v1.47.11](https://github.com/aws/aws-sdk-go/releases/tag/v1.47.11)
+ Go v2 : [release-2023-11-14](https://github.com/aws/aws-sdk-go-v2/releases/tag/release-2023-11-14)
+ Python (Boto3) : [1.34.41](https://github.com/boto/boto3/releases/tag/1.34.41)
+ Python (botocore) : [1.34.41](https://github.com/boto/botocore/releases/tag/1.34.41)
+ AWS CLI : [1.30.0](https://github.com/aws/aws-cli/releases/tag/1.30.0)
AWS CLI : [2.15.0](https://github.com/aws/aws-cli/releases/tag/2.15.0)
+ JavaScript v2 : [2.1550.0](https://github.com/aws/aws-sdk-js/releases/tag/v2.1550.0)
+ JavaScript v3 : [v3.458.0](https://github.com/aws/aws-sdk-js-v3/releases/tag/v3.458.0)
+ Kotlin : [v1.0.1](https://github.com/awslabs/aws-sdk-kotlin/releases/tag/v1.0.1)
+ Ruby : [3.188.0](https://github.com/aws/aws-sdk-ruby/blob/version-3/gems/aws-sdk-core/CHANGELOG.md#31880-2023-11-22)
+ Rust : [release-2024-03-13](https://github.com/awslabs/aws-sdk-rust/releases/tag/release-2024-03-13)
+ C\$1\$1 : [1.11.263](https://github.com/aws/aws-sdk-cpp/releases/tag/1.11.263)
+ .NET : [3.7.734.0](https://github.com/aws/aws-sdk-net/releases/tag/3.7.734.0)
+ PowerShell : [4.1.502](https://www.powershellgallery.com/packages/AWS.Tools.Common/4.1.502)
+ PHP : [3.289.0](https://github.com/aws/aws-sdk-php/releases/tag/3.287.1)
Pour vous assurer d’utiliser un kit SDK pris en charge, suivez les instructions d’installation relatives à votre SDK préféré de la page [Tools to Build on AWS](https://aws.amazon.com/tools/) lorsque vous créez vos conteneurs.
Pour obtenir la liste des modules complémentaires qui prennent en charge l’identité du pod EKS, consultez [Référence relative à la prise en charge de l’identité du pod](retreive-iam-info.md#pod-id-add-on-versions).
# Désactiver `IPv6` dans l’agent d’identité du pod EKS
## AWS Management Console
1. Pour désactiver `IPv6` dans l’agent d’identité du pod EKS, ajoutez la configuration suivante aux **Paramètres de configuration facultatifs** du module complémentaire EKS.
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dans le panneau de navigation de gauche, sélectionnez **Clusters**, puis sélectionnez le nom du cluster pour lequel vous souhaitez configurer le module complémentaire.
1. Choisissez l'onglet **Modules complémentaires**.
1. Cochez la case en haut à droite de la case du module complémentaire identité du pod EKS, puis sélectionnez **Modifier**.
1. Sur la page **Configurer l’agent d’identité du pod EKS** :
1. Sélectionnez la **version** que vous souhaitez utiliser. Il est recommandé de conserver la même version que celle de l’étape précédente et d’effectuer la mise à jour de la version et de la configuration séparément.
1. Sélectionnez **Paramètres de configuration facultatifs**.
1. Saisissez la clé JSON `"agent":` et la valeur d’un objet JSON imbriqué avec une clé `"additionalArgs":` dans **Valeurs de configuration**. Le texte obtenu doit être un objet JSON valide. Si cette clé et cette valeur sont les seules données de la zone de texte, entourez-les d'accolades `{ }`. L’exemple suivant montre que la politique réseau est activée :
```
{
"agent": {
"additionalArgs": {
"-b": "169.254.170.23"
}
}
}
```
Cette configuration définit l’adresse `IPv4` comme seule adresse utilisée par l’agent.
1. Pour appliquer la nouvelle configuration en remplaçant les pods de l’agent d’identité du pod EKS, sélectionnez **Enregistrer les modifications**.
Amazon EKS applique les modifications aux modules complémentaires Amazon EKS à l’aide d’un *déploiement* du `DaemonSet` Kubernetes pour l’agent d’identité du pod EKS. Vous pouvez suivre l’état du déploiement dans l’**Historique des mises à jour** du module complémentaire, dans AWS Management Console, ainsi qu’à l’aide de `kubectl rollout status daemonset/eks-pod-identity-agent --namespace kube-system`.
L’outil `kubectl rollout` propose les commandes suivantes :
```
$ kubectl rollout
history -- View rollout history
pause -- Mark the provided resource as paused
restart -- Restart a resource
resume -- Resume a paused resource
status -- Show the status of the rollout
undo -- Undo a previous rollout
```
Si le déploiement prend trop de temps, Amazon EKS annule automatiquement le déploiement, et un message indiquant un type de **Mise à jour du module complémentaire** avec un état **Échec** est ajouté à l’**Historique des mises à jour** du module complémentaire. Pour examiner tout problème, commencez par l’historique du déploiement, puis journalisez `kubectl logs` sur un pod de l’agent d’identité du pod EKS pour afficher les journaux de l’agent d’identité du pod EKS.
1. Si la nouvelle entrée dans **Historique des mises à jour** a le statut **Réussi**, cela signifie que le déploiement est terminé et que le module complémentaire utilise la nouvelle configuration dans tous les pods de l’agent d’identité du pod EKS.
## AWS CLI
1. Pour désactiver `IPv6` dans l’agent d’identité du pod EKS, ajoutez la configuration suivante aux **valeurs de configuration** du module complémentaire EKS.
Exécutez la commande AWS CLI suivante. Remplacez `my-cluster` par le nom de votre cluster et l'ARN du rôle IAM par le rôle que vous utilisez.
```
aws eks update-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent \
--resolve-conflicts PRESERVE --configuration-values '{"agent":{"additionalArgs": { "-b": "169.254.170.23"}}}'
```
Cette configuration définit l’adresse `IPv4` comme seule adresse utilisée par l’agent.
Amazon EKS applique les modifications aux modules complémentaires EKS à l’aide d’un *déploiement* du DaemonSet Kubernetes pour l’Agent d’identité du pod EKS. Vous pouvez suivre l’état du déploiement dans l’**Historique des mises à jour** du module complémentaire, dans AWS Management Console, ainsi qu’à l’aide de `kubectl rollout status daemonset/eks-pod-identity-agent --namespace kube-system`.
L’outil `kubectl rollout` propose les commandes suivantes :
```
kubectl rollout
history -- View rollout history
pause -- Mark the provided resource as paused
restart -- Restart a resource
resume -- Resume a paused resource
status -- Show the status of the rollout
undo -- Undo a previous rollout
```
Si le déploiement prend trop de temps, Amazon EKS annule automatiquement le déploiement, et un message indiquant un type de **Mise à jour du module complémentaire** avec un état **Échec** est ajouté à l’**Historique des mises à jour** du module complémentaire. Pour examiner tout problème, commencez par l’historique du déploiement, puis journalisez `kubectl logs` sur un pod de l’agent d’identité du pod EKS pour afficher les journaux de l’agent d’identité du pod EKS.
# Créer un rôle IAM avec la politique d’approbation requise par l’identité du pod EKS
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
** `sts:AssumeRole` **
L’identité du pod EKS utilise `AssumeRole` pour assumer le rôle IAM avant de transmettre les informations d’identification temporaires à vos pods.
** `sts:TagSession` **
EKS Pod `TagSession` Identity inclut des *balises de session* dans les demandes adressées à AWS STS.
**Conditions de configuration**
Vous pouvez utiliser ces balises dans les *clés de condition* de la politique d’approbation pour restreindre les comptes de service, les espaces de noms et les clusters pouvant utiliser ce rôle. Pour obtenir la liste des balises de requête ajoutées par l’identité du pod, consultez [Activer ou désactiver les balises de session](pod-id-abac.md#pod-id-abac-tags).
Par exemple, vous pouvez limiter les pods pouvant assumer le rôle IAM d’identité du pod à un `ServiceAccount` et un `Namespace` spécifiques à l’aide de la politique d’approbation suivante avec la `Condition` ajoutée :
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/kubernetes-namespace": [
"Namespace"
],
"aws:RequestTag/kubernetes-service-account": [
"ServiceAccount"
]
}
}
}
]
}
```
Pour obtenir la liste des clés de condition Amazon EKS, consultez la rubrique [Conditions définies par Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys) de la *Référence de l'autorisation de service*. Pour savoir avec quelles actions et ressources vous pouvez utiliser une clé de condition, consultez la rubrique [Actions définies par Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions).