**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.
# Sécurité dans Amazon EKS
La sécurité du cloud AWS est la priorité absolue. En tant que AWS client, vous bénéficiez d'un centre de données et d'une architecture réseau conçus pour répondre aux exigences des entreprises les plus sensibles en matière de sécurité.
La sécurité est une responsabilité partagée entre vous AWS et vous. Le [modèle de responsabilité partagée](https://aws.amazon.com/compliance/shared-responsibility-model/) décrit cette notion par les termes sécurité *du* cloud et sécurité *dans* le cloud :
+ **Sécurité du cloud** : AWS est chargée de protéger l'infrastructure qui exécute les AWS services dans le AWS cloud. Pour Amazon EKS, AWS est responsable du plan de contrôle Kubernetes, qui inclut les nœuds et la base de données du plan de contrôle. `etcd` Des auditeurs tiers testent et vérifient régulièrement l’efficacité de notre sécurité dans le cadre des [programmes de conformitéAWS](https://aws.amazon.com/compliance/programs/). Pour en savoir plus sur les programmes de conformité qui s'appliquent à Amazon EKS, consultez [Services AWS concernés par le programme de conformité](https://aws.amazon.com/compliance/services-in-scope/).
+ **Sécurité dans le cloud** : votre responsabilité englobe les domaines suivants :
+ La configuration de sécurité du plan de données, y compris la configuration des groupes de sécurité qui autorisent le trafic à transmettre à partir du plan de contrôle Amazon EKS dans le VPC client.
+ La configuration des nœuds et les conteneurs eux-mêmes
+ Le système d’exploitation du nœud (y compris les mises à jour et les correctifs de sécurité)
+ D'autres logiciels d'application connexes :
+ Configuration et gestion des contrôles réseau, tels que les règles de pare-feu
+ La gestion de l'identité au niveau de la plateforme et la gestion des accès, avec ou en complément de l'IAM
+ La sensibilité de vos données, les exigences de votre entreprise,et la législation et la réglementation applicables
Amazon EKS est certifié par plusieurs programmes de conformité pour les applications réglementées et sensibles. Amazon EKS est conforme aux normes [SOC](https://aws.amazon.com/compliance/soc-faqs/), [PCI](https://aws.amazon.com/compliance/pci-dss-level-1-faqs/), [ISO](https://aws.amazon.com/compliance/iso-certified/), [FedRAMP-Moderate](https://aws.amazon.com/compliance/fedramp/), [IRAP](https://aws.amazon.com/compliance/irap/), [C5](https://aws.amazon.com/compliance/bsi-c5/), [K-ISMS](https://aws.amazon.com/compliance/k-isms/), [ENS High](https://aws.amazon.com/compliance/esquema-nacional-de-seguridad/), [OSPAR](https://aws.amazon.com/compliance/OSPAR/), [HITRUST CSF](https://aws.amazon.com/compliance/hitrust/) et est un service éligible [HIPAA](https://aws.amazon.com/compliance/hipaa-compliance/). Pour de plus amples informations, veuillez consulter [Présentation du fonctionnement du contrôle d’accès dans Amazon EKS](cluster-auth.md).
Cette documentation vous aide à comprendre comment appliquer le modèle de responsabilité partagée lors de l'utilisation d'Amazon EKS. Les rubriques suivantes vous montrent comment configurer Amazon EKS pour répondre à vos objectifs de sécurité et de conformité. Vous apprendrez également à utiliser d'autres AWS services qui vous aident à surveiller et à sécuriser vos ressources Amazon EKS.
**Note**
Les conteneurs Linux sont constitués de groupes de contrôle (cgroups) et d'espaces de noms qui aident à limiter les accès auxquels un conteneur peut accéder, mais tous les conteneurs partagent le même noyau Linux que l'instance Amazon EC2 hôte. L'exécution d'un conteneur en tant qu'utilisateur racine (UID 0) ou l'octroi d'un accès à un conteneur aux ressources hôtes ou aux espaces de noms tels que le réseau hôte ou l'espace de noms PID hôte sont fortement déconseillés, car cela réduit l'efficacité de l'isolation fournie par les conteneurs.
**Topics**
+ [Sécuriser les clusters Amazon EKS avec les bonnes pratiques](security-best-practices.md)
+ [Analyse des vulnérabilités dans Amazon EKS](configuration-vulnerability-analysis.md)
+ [Validation de la conformité des clusters Amazon EKS](compliance.md)
+ [Considérations relatives à la sécurité pour Amazon Elastic Kubernetes Service](security-eks.md)
+ [Considérations de sécurité pour Kubernetes](security-k8s.md)
+ [Considérations de sécurité relatives au mode automatique Amazon EKS](auto-security.md)
+ [Considérations relatives à la sécurité relatives aux fonctionnalités EKS](capabilities-security.md)
+ [Gestion des identités et des accès pour Amazon EKS](security-iam.md)
# Sécuriser les clusters Amazon EKS avec les bonnes pratiques
Les bonnes pratiques de sécurité Amazon EKS se trouvent dans la section [Bonnes pratiques en matière de sécurité](https://docs.aws.amazon.com/eks/latest/best-practices/security.html) du *Guide des bonnes pratiques Amazon EKS*.
# Analyse des vulnérabilités dans Amazon EKS
La sécurité est une considération cruciale pour la configuration et la maintenance des clusters et des applications Kubernetes. Vous trouverez ci-dessous la liste des ressources vous permettant d’analyser la configuration de sécurité de vos clusters EKS, les outils pour vérifier les vulnérabilités, ainsi que les intégrations avec les services AWS qui peuvent effectuer cette analyse pour vous.
## Référence Center for Internet Security (CIS) pour Amazon EKS
La [Référence Kubernetes du Center for Internet Security (CIS)](https://www.cisecurity.org/benchmark/kubernetes/) fournit des conseils sur les configurations de sécurité des nœuds Amazon EKS. Le benchmark :
+ S'applique aux nœuds Amazon EC2 (gérés et autogérés) dans lesquels vous êtes responsable des configurations de sécurité des composants Kubernetes.
+ Fournit un moyen standard approuvé par la communauté de vous assurer que vous avez configuré votre cluster et vos nœuds Kubernetes en toute sécurité lors de l'utilisation d'Amazon EKS.
+ Se compose de quatre sections : configuration de journalisation du plan de contrôle, configurations de sécurité des nœuds, politiques et services managés.
+ Prend en charge toutes les versions de Kubernetes actuellement disponibles dans Amazon EKS et peut être exécuté à l'aide de [kube-bench](https://github.com/aquasecurity/kube-bench), un outil open source standard pour vérifier la configuration à l'aide du benchmark CIS sur les clusters Kubernetes.
Pour en savoir plus, consultez [Présentation de la norme CIS Amazon EKS](https://aws.amazon.com/blogs/containers/introducing-cis-amazon-eks-benchmark).
Pour un pipeline `aws-sample` automatisé permettant de mettre à jour votre groupe de nœuds avec une image AMI conforme à la référence CIS, consultez [Pipeline de renforcement des AMI optimisées EKS](https://github.com/aws-samples/pipeline-for-hardening-eks-nodes-and-automating-updates).
## Versions de plateforme Amazon EKS
Les *versions de la plateforme* Amazon EKS représentent les fonctionnalités du plan de contrôle du cluster, y compris les indicateurs activés du serveur d’API Kubernetes ainsi que la version actuelle du correctif Kubernetes. Les nouveaux clusters sont déployés avec la dernière version de la plateforme. Pour plus de détails, consultez [Versions de plateforme EKS](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html).
Vous pouvez mettre à jour un [cluster Amazon EKS](update-cluster.md) vers de nouvelles versions Kubernetes. À mesure que de nouvelles versions Kubernetes deviennent disponibles dans Amazon EKS, nous vous recommandons de mettre à jour de manière proactive vos clusters pour utiliser la dernière version disponible. Pour plus d’informations sur les versions de Kubernetes prises en charge dans EKS, consultez [Versions prises en charge par Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
## Liste des vulnérabilités du système d’exploitation
### Liste des vulnérabilités AL2023
Suivez les évènements de sécurité et de confidentialité pour Amazon Linux 2023 via le [centre de sécurité Amazon Linux](https://alas.aws.amazon.com/alas2023.html) ou souscrivez au [flux RSS](https://alas.aws.amazon.com/AL2023/alas.rss) associé. Les événements de sécurité et de confidentialité incluent une présentation du problème, des packages et des instructions relatives à la mise à jour de vos instances pour résoudre le problème.
### Liste des vulnérabilités Amazon Linux 2
Suivez les évènements de sécurité et de confidentialité pour Amazon Linux 2 via le [centre de sécurité Amazon Linux](https://alas.aws.amazon.com/alas2.html) ou souscrivez au [flux RSS](https://alas.aws.amazon.com/AL2/alas.rss) associé. Les événements de sécurité et de confidentialité incluent une présentation du problème, des packages et des instructions relatives à la mise à jour de vos instances pour résoudre le problème.
## Détection de nœuds avec Amazon Inspector
Vous pouvez utiliser [Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/userguide/inspector_introduction.html) pour vérifier l'accessibilité réseau indésirable de vos nœuds et les vulnérabilités de ces instances Amazon EC2.
## Détection de clusters et de nœuds avec Amazon GuardDuty
Amazon GuardDuty est un service de détection des menaces qui vous aide à protéger vos comptes, vos conteneurs, vos charges de travail et les données de votre environnement AWS. Parmi d’autres fonctionnalités, GuardDuty offre les deux fonctionnalités suivantes qui détectent les menaces potentielles pour vos clusters EKS : *Protection EKS* et *Surveillance de l’exécution*.
Pour de plus amples informations, consultez [Détectez les menaces avec Amazon GuardDuty](integration-guardduty.md).
# Validation de la conformité des clusters Amazon EKS
Pour savoir si un service AWS est inclus dans le périmètre d’un programme de conformité spécifique, consultez [Services AWS inclus dans le périmètre par programme de conformité](https://aws.amazon.com/compliance/services-in-scope/), puis sélectionnez le programme de conformité qui vous intéresse. Pour obtenir des informations générales, consultez [Programmes de conformité AWS](https://aws.amazon.com/compliance/programs/).
Vous pouvez télécharger les rapports d’audit de tiers à l’aide de l’artefact AWS. Pour plus d’informations, consultez [Téléchargement des rapports dans AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Votre responsabilité en matière de conformité lorsque vous utilisez des services AWS dépend de la sensibilité de vos données, des objectifs de conformité de votre entreprise, ainsi que des lois et réglementations applicables. AWS fournit les ressources suivantes pour vous aider à respecter ces exigences de conformité :
+ [Conformité et gouvernance de la sécurité](https://aws.amazon.com/solutions/security/security-compliance-governance/) : ces guides de mise en œuvre de solutions traitent des considérations architecturales et fournissent les étapes à suivre afin de déployer des fonctionnalités de sécurité et de conformité.
+ [Référence des services éligibles HIPAA](https://aws.amazon.com/compliance/hipaa-eligible-services-reference/) : liste les services éligibles HIPAA. Tous les services AWS ne sont pas admissibles à la norme HIPAA.
+ [Ressources de conformité AWS](https://aws.amazon.com/compliance/resources/) : cet ensemble de manuels et de guides peut s’appliquer à votre secteur et à votre emplacement.
+ [AWSGuides de conformité destinés aux clients](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf) — Comprenez le modèle de responsabilité partagée sous l’angle de la conformité. Les guides résument les meilleures pratiques pour sécuriser les services AWS et établissent une correspondance entre ces pratiques et les contrôles de sécurité définis par plusieurs cadres de référence, notamment l’Institut national de normalisation et de technologie (NIST), le Conseil de normes de sécurité PCI (Payment Card Industry) et l’Organisation internationale de normalisation (ISO).
+ [Évaluation des ressources à l’aide de règles](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) dans le *Guide du développeur AWS Config* : le service AWS Config évalue dans quelle mesure vos configurations de ressources sont conformes aux pratiques internes, aux lignes directrices de l’industrie et aux réglementations.
+ [AWS Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) : ce service AWS fournit une vue complète de votre état de sécurité au sein d’AWS. Security Hub utilise des contrôles de sécurité pour évaluer vos ressources AWS et vérifier votre conformité par rapport aux normes et aux bonnes pratiques du secteur de la sécurité. Pour obtenir la liste des services et des contrôles pris en charge, consultez [Référence des contrôles Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html).
+ [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html) : ce service AWS permet de détecter les menaces potentielles pesant sur vos comptes AWS, vos charges de travail, vos conteneurs et vos données, en surveillant votre environnement à la recherche d’activités suspectes ou malveillantes. GuardDuty peut vous aider à satisfaire diverses exigences de conformité, comme la conformité à la norme PCI DSS, en répondant aux exigences de détection d’intrusion imposées par certains frameworks de conformité.
+ [AWS Audit Manager](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html) – Ce service AWS vous aide à auditer en permanence votre utilisation de AWS afin de simplifier la gestion des risques et la conformité aux réglementations et aux normes du secteur.
# Considérations relatives à la sécurité pour Amazon Elastic Kubernetes Service
Voici quelques considérations relatives à la sécurité du cloud, car elles affectent Amazon EKS.
**Topics**
+ [Sécurité de l'infrastructure dans Amazon EKS](infrastructure-security.md)
+ [Comprendre la résilience dans les clusters Amazon EKS](disaster-recovery-resiliency.md)
+ [Prévention des conflits entre services dans Amazon EKS](cross-service-confused-deputy-prevention.md)
# Sécurité de l'infrastructure dans Amazon EKS
En tant que service géré, Amazon Elastic Kubernetes Service bénéficie de la sécurité offerte par le réseau mondial AWS. Pour plus d’informations sur les services de sécurité AWS et la manière dont AWS protège l’infrastructure, consultez la section [Sécurité du cloud AWS](https://aws.amazon.com/security/). Pour concevoir votre environnement AWS en utilisant les meilleures pratiques en matière de sécurité de l’infrastructure, consultez la section [Protection de l’infrastructure](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) dans le *Security Pillar AWS Well‐Architected Framework* (Pilier de sécurité de l’infrastructure Well‐Architected Framework).
Vous utilisez les appels d'API publiés par AWS pour accéder à Amazon EKS via le réseau. Les clients doivent prendre en charge les éléments suivants :
+ Protocole TLS (Transport Layer Security). Nous exigeons TLS 1.2 et recommandons TLS 1.3.
+ Ses suites de chiffrement PFS (Perfect Forward Secrecy) comme DHE (Ephemeral Diffie-Hellman) ou ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). La plupart des systèmes modernes tels que Java 7 et les versions ultérieures prennent en charge ces modes.
En outre, les demandes doivent être signées à l’aide d’un ID de clé d’accès et d’une clé d’accès secrète associée à un principal IAM. Vous pouvez également utiliser le [Service de jetons de sécurité AWS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) (AWS STS) pour générer des informations d’identification de sécurité temporaires afin de signer les demandes.
Lorsque vous créez un cluster Amazon EKS, vous spécifiez les sous-réseaux VPC à utiliser par votre cluster. Amazon EKS nécessite des sous-réseaux dans au moins deux zones de disponibilité. Nous recommandons un VPC avec des sous-réseaux publics et privés afin que Kubernetes puisse créer des équilibreurs de charge publics dans les sous-réseaux publics qui équilibrent le trafic vers des pods s’exécutant sur des nœuds qui se trouvent dans des sous-réseaux privés.
Pour plus d'informations sur les considérations VPC, consultez [Afficher les exigences réseau Amazon EKS pour les VPC et les sous-réseaux](network-reqs.md).
Si vous créez votre VPC et vos groupes de nœuds à l’aide des modèles CloudFormation AWS fournis dans le [Guide de démarrage Amazon EKS](getting-started.md), votre plan de contrôle et vos groupes de sécurité de nœuds sont configurés avec nos paramètres recommandés.
Pour plus d'informations sur les considérations des groupes de sécurité, consultez [Voir les exigences relatives aux groupes de sécurité Amazon EKS pour les clusters](sec-group-reqs.md).
Lorsque vous créez un cluster, Amazon EKS crée un point de terminaison pour le serveur d'API Kubernetes géré que vous utilisez pour communiquer avec votre cluster (à l'aide d'outils de gestion Kubernetes comme `kubectl`). Par défaut, ce point de terminaison du serveur d’API est public sur Internet, et l’accès au serveur d’API est sécurisé à l’aide d’une combinaison de la gestion des identités et des accès AWS (IAM) et du [contrôle d’accès basé sur les rôles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) natif de Kubernetes.
Vous pouvez activer l'accès privé au serveur d'API Kubernetes pour que toutes les communications entre vos nœuds et le serveur d'API restent au sein de votre VPC. Vous pouvez limiter les adresses IP qui peuvent accéder à votre serveur API à partir d'Internet, ou désactiver complètement l'accès Internet au serveur d'API.
Pour plus d'informations sur la modification de l'accès au point de terminaison de cluster, consultez [Modification de l'accès au point de terminaison de cluster](cluster-endpoint.md#modify-endpoint-access).
Vous pouvez mettre en œuvre les *politiques réseau* Kubernetes avec Amazon VPC CNI ou des outils tiers tels que [Project Calico](https://docs.tigera.io/calico/latest/about/). Pour plus d'informations sur l'utilisation de l'Amazon VPC CNI pour les stratégies réseau, consultez [Limitation du trafic des pods à l’aide des politiques réseau Kubernetes](cni-network-policy.md). Project Calico tiers est un projet open source tierce. Pour plus d'informations, consultez la documentation [Project Calico](https://docs.tigera.io/calico/latest/getting-started/kubernetes/managed-public-cloud/eks/).
# Accéder à Amazon EKS à l’aide d’AWS PrivateLink
Vous pouvez utiliser AWS PrivateLink pour créer une connexion privée entre votre VPC et Amazon Elastic Kubernetes Service. Vous pouvez accéder à Amazon EKS comme s’il se trouvait dans votre VPC, sans utiliser de passerelle Internet, de dispositif NAT, de connexion VPN ou de connexion AWS Direct Connect. Les instances de votre VPC n’ont pas besoin d’adresses IP publiques pour accéder à Amazon EKS.
Vous établissez cette connexion privée en créant un point de terminaison d’interface à technologie AWS PrivateLink. Nous créons une interface réseau de point de terminaison dans chaque sous-réseau que vous activez pour le point de terminaison d’interface. Il s'agit d'interfaces réseau gérées par le demandeur qui servent de point d'entrée pour le trafic destiné à Amazon EKS.
Pour plus d’informations, consultez [Accéder aux services AWS via AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html) dans le * Guide AWS PrivateLink*.
## Avant de commencer
Avant de commencer, assurez-vous d’avoir effectué les tâches suivantes :
+ Consultez la section [Accéder à un service AWS à l’aide d’un point de terminaison d’un VPC d’interface](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints) dans le * Guide AWS PrivateLink*
## Considérations
+ **Assistance et limitations** : les points de terminaison d’interface Amazon EKS permettent un accès sécurisé à toutes les actions de l’API Amazon EKS à partir de votre VPC, mais ils sont soumis à certaines limitations : ils ne prennent pas en charge l’accès aux API Kubernetes, car celles-ci disposent d’un point de terminaison privé distinct. Vous ne pouvez pas configurer Amazon EKS pour qu’il soit accessible uniquement via le point de terminaison d’interface.
+ **Tarification** : l’utilisation de points de terminaison d’interface pour Amazon EKS entraîne des frais AWS PrivateLink standard : frais horaires pour chaque point de terminaison provisionné dans chaque zone de disponibilité, frais de traitement des données pour le trafic passant par le point de terminaison. Pour en savoir plus, consultez [Tarification AWS PrivateLink](https://aws.amazon.com/privatelink/pricing/).
+ **Sécurité et contrôle d’accès** : nous vous recommandons de renforcer la sécurité et de contrôler l’accès à l’aide de ces configurations supplémentaires : utilisez les politiques de point de terminaison d’un VPC pour contrôler l’accès à Amazon EKS via le point de terminaison d’interface, associez des groupes de sécurité aux interfaces réseau des points de terminaison pour gérer le trafic, utilisez les journaux de flux VPC pour capturer et surveiller le trafic IP vers et depuis les points de terminaison d’interface, avec des journaux pouvant être diffusés sur Amazon CloudWatch ou Amazon S3. Pour en savoir plus, consultez [Contrôle de l’accès aux points de terminaison d’un VPC à l’aide des politiques de point de terminaison](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) et [Journalisation du trafic IP à l’aide des journaux de flux VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html).
+ **Options de connectivité** : les points de terminaison d’interface offrent des options de connectivité flexibles à l’aide de l’**accès sur site** (connectez votre centre de données sur site à un VPC avec le point de terminaison d’interface à l’aide d’AWS Direct Connect ou d’AWS Site-to-Site VPN) ou via la **connectivité inter-VPC** (utilisez AWS Transit Gateway ou le peering VPC pour connecter d’autres VPC au VPC avec le point de terminaison d’interface, en conservant le trafic au sein du réseau AWS). .
+ **Prise en charge des versions IP** : les points de terminaison créés avant août 2024 prennent uniquement en charge IPv4 à l’aide de eks.region.amazonaws.com. Les nouveaux points de terminaison créés après août 2024 prennent en charge la double pile IPv4 et IPv6 (par exemple, eks.region.amazonaws.com, eks.region.api.aws).
+ **Disponibilité régionale** : AWS PrivateLink pour l’API EKS n’est pas disponible dans les régions Asie-Pacifique (Malaisie) (ap-southeast-5), Asie-Pacifique (Thaïlande) (ap-southeast-7), Mexique (Centre) (mx-central-1) et Asie-Pacifique (Taipei) (ap-east-2). AWS PrivateLink pour eks-auth (Identité du pod Amazon EKS) est disponible dans la région Asie-Pacifique (Malaisie) (ap-southeast-5).
## Créer un point de terminaison d'interface pour Amazon EKS
Vous pouvez créer un point de terminaison d’un VPC pour Amazon EKS à l’aide de la console Amazon VPC ou de l’interface de ligne de commande AWS (AWS CLI). Pour plus d’informations, consultez [Créer un point de terminaison d’un VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws) dans le * Guide AWS PrivateLink*.
Créez un point de terminaison d’interface pour Amazon EKS à l’aide des noms de service suivants :
### API EKS
+ com.amazonaws.region-code.eks
+ com.amazonaws.code-région.eks-fips (pour les points de terminaison conformes à la norme FIPS)
### API EKS Auth (Identité du pod EKS)
+ com.amazonaws.region-code.eks-auth
## Fonctionnalité DNS privée pour les points de terminaison d’interface Amazon EKS
La fonctionnalité DNS privée, activée par défaut pour les points de terminaison d’interface d’Amazon EKS et d’autres services AWS, facilite les demandes API sécurisées et privées à l’aide des noms DNS régionaux par défaut. Cette fonctionnalité garantit que les appels d’API sont routés via le point de terminaison d’interface sur le réseau AWS privé, ce qui améliore la sécurité et les performances.
La fonctionnalité DNS privés s’active automatiquement lorsque vous créez un point de terminaison d’interface pour Amazon EKS ou d’autres services AWS. Pour l’activer, vous devez configurer correctement votre VPC en définissant des attributs spécifiques :
+ **enableDnsHostnames** : permet aux instances au sein du VPC d’avoir des noms d’hôte DNS.
+ **enableDnsSupport** : active la résolution DNS dans l’ensemble du VPC.
Pour obtenir des instructions détaillées sur la vérification ou la modification de ces paramètres, consultez [Afficher et mettre à jour les attributs DNS de votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating).
### Noms DNS et types d’adresses IP
Lorsque la fonctionnalité DNS privés est activée, vous pouvez utiliser des noms DNS spécifiques pour vous connecter à Amazon EKS. Ces options évoluent au fil du temps :
+ **eks.region.amazonaws.com** : le nom DNS traditionnel, qui ne résout que les adresses IPv4 avant août 2024. Pour les points de terminaison existants mis à jour vers la double pile, ce nom résout à la fois les adresses IPv4 et IPv6.
+ **eks.region.api.aws** : disponible pour les nouveaux points de terminaison créés après août 2024, ce nom DNS à double pile résout à la fois les adresses IPv4 et IPv6.
Après août 2024, les nouveaux points de terminaison d’interface seront fournis avec deux noms DNS, et vous pourrez opter pour le type d’adresse IP double pile. Pour les points de terminaison existants, la mise à jour vers la double pile modifie **eks.region.amazonaws.com** afin de prendre en charge à la fois IPv4 et IPv6.
### Utilisation de la fonctionnalité DNS privés
Une fois configurée, la fonctionnalité DNS privés peut être intégrée à vos flux de travail, offrant les capacités suivantes :
+ **Requêtes API** : utilisez les noms DNS régionaux par défaut, `eks.region.amazonaws.com` ou `eks.region.api.aws`, en fonction de la configuration de votre point de terminaison pour effectuer des requêtes API vers Amazon EKS.
+ **Compatibilité des applications** : vos applications existantes qui appellent les API EKS ne nécessitent aucune modification pour tirer parti de cette fonctionnalité.
+ ** AWS CLI avec double pile** : pour utiliser les points de terminaison à double pile avec l’AWS CLI, consultez la configuration [Points de terminaison à double pile et FIPS](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html) dans le * Guide de référence des SDK et outils AWS*.
+ **Routage automatique** : tout appel vers le point de terminaison de service par défaut d’Amazon EKS est automatiquement dirigé vers le point de terminaison de l’interface, garantissant ainsi une connectivité privée et sécurisée.
# Comprendre la résilience dans les clusters Amazon EKS
L’infrastructure mondiale AWS s’articule autour de régions et de zones de disponibilité AWS. AWS Les régions fournissent plusieurs zones de disponibilité physiquement séparées et isolées, reliées par un réseau à latence faible, à haut débit et hautement redondant. Avec les zones de disponibilité, vous pouvez concevoir et exploiter des applications et des bases de données qui basculent automatiquement d’une zone de disponibilité à l’autre sans interruption. Les zones de disponibilité sont plus hautement disponibles, tolérantes aux pannes et évolutives que les infrastructures traditionnelles à un ou plusieurs centres de données.
Amazon EKS exécute et met à l'échelle des instances de plan de contrôle Kubernetes sur plusieurs zones de disponibilité AWS, ce qui permet d'assurer une haute disponibilité. Amazon EKS met automatiquement à l'échelle les instances du plan de contrôle en fonction de la charge, détecte et remplace les instances du plan de contrôle non saines, et applique automatiquement des correctifs au plan de contrôle. Après que vous ayez lancé une mise à jour de version, Amazon EKS met à jour votre plan de contrôle pour vous, en maintenant la haute disponibilité du plan de contrôle pendant la mise à jour.
Ce plan de contrôle se compose d’au moins deux instances de serveur API et trois instances `etcd` qui s’exécutent sur trois zones de disponibilité au sein d’une région AWS. Amazon EKS :
+ Surveille activement la charge sur les instances de plan de contrôle et les met automatiquement à l'échelle pour garantir des performances élevées.
+ Détecte et remplace automatiquement les instances de plan de contrôle défaillantes, en les redémarrant dans les zones de disponibilité de la région AWS si nécessaire.
+ Exploite l'architecture des régions AWS afin de maintenir une haute disponibilité. De ce fait, Amazon EKS peut offrir un [accord de niveau de service (SLA) pour la disponibilité des points de terminaison de serveur d'API](https://aws.amazon.com/eks/sla).
Pour plus d'informations sur les régions et les zones de disponibilité AWS, consultez [Infrastructure mondiale AWS](https://aws.amazon.com/about-aws/global-infrastructure/).
# Prévention des conflits entre services dans Amazon EKS
Le problème de député confus est un problème de sécurité dans lequel une entité qui n’est pas autorisée à effectuer une action peut contraindre une entité plus privilégiée à le faire. En AWS, l'usurpation d'identité interservices peut entraîner la confusion des adjoints. L’usurpation d’identité entre services peut se produire lorsqu’un service (le *service appelant*) appelle un autre service (le *service appelé*). Le service appelant peut être manipulé et ses autorisations utilisées pour agir sur les ressources d’un autre client auxquelles on ne serait pas autorisé d’accéder autrement. Pour éviter cela, AWS fournit des outils qui vous aident à protéger vos données pour tous les services auprès des principaux fournisseurs de services qui ont obtenu l'accès aux ressources de votre compte.
Nous vous recommandons d’utiliser les clés de contexte de condition globale [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn), [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) dans les politiques de ressources afin de limiter les autorisations accordées par Amazon Elastic Kubernetes Service (Amazon EKS) à un autre service pour la ressource.
`aws:SourceArn`
Utilisez `aws:SourceArn` pour associer une seule ressource à l’accès interservice.
`aws:SourceAccount`
Utilisez `aws:SourceAccount` pour permettre à n’importe quelle ressource de ce compte d’être associée à l’utilisation interservice.
Le moyen le plus efficace de se protéger contre le problème de député confus consiste à utiliser la clé de contexte de condition globale `aws:SourceArn` avec l’ARN complet de la ressource. Si vous ne connaissez pas l’ARN complet de la ressource ou si vous spécifiez plusieurs ressources, utilisez la clé de condition de contexte global `aws:SourceArn` avec des caractères génériques (\$1) pour les parties inconnues de l’ARN. Par exemple, ` arn:aws::*:<123456789012>:*`.
Si la valeur `aws:SourceArn` ne contient pas l'ID du compte, tel qu'un ARN de compartiment Amazon S3, vous devez utiliser à la fois `aws:SourceAccount` et `aws:SourceArn` pour limiter les autorisations.
## Prévention des conflits entre services dans les rôles de cluster Amazon EKS
Un rôle IAM du cluster Amazon EKS est requis pour chaque cluster. Les clusters Kubernetes gérés par Amazon EKS utilisent ce rôle pour gérer les nœuds, tandis que [l’ancien fournisseur de cloud](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider) utilise ce rôle pour créer des équilibreurs de charge avec Elastic Load Balancing pour les services. Ces actions de cluster ne peuvent affecter que le même compte. Nous vous recommandons donc de limiter chaque rôle de cluster à ce cluster et à ce compte. Il s'agit d'une application spécifique de la AWS recommandation de respecter le *principe du moindre privilège* dans votre compte.
**Format source ARN**
La valeur de `aws:SourceArn` doit être l’ARN d’un cluster EKS au format ` arn:aws: eks:region:account:cluster/cluster-name `. Par exemple, ` arn:aws: eks:us-west-2:123456789012:cluster/my-cluster`.
**Format de stratégie de confiance pour les rôles de cluster EKS**
L’exemple suivant montre comment vous pouvez utiliser les clés de contexte de condition globale `aws:SourceArn` et `aws:SourceAccount` dans Amazon EKS pour éviter le problème de l’adjoint confus.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-west-2:123456789012:cluster/my-cluster"
},
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
}
]
}
```
# Considérations de sécurité pour Kubernetes
Voici quelques considérations relatives à la sécurité dans le cloud, car elles affectent Kubernetes dans les clusters Amazon EKS. Pour une analyse approfondie des contrôles et des pratiques de sécurité dans Kubernetes, consultez [Sécurité native cloud et Kubernetes](https://kubernetes.io/docs/concepts/security/cloud-native-security/) dans la documentation Kubernetes.
**Topics**
+ [Sécurisation des charges de travail grâce aux certificats Kubernetes](cert-signing.md)
+ [Comprendre les rôles RBAC et les utilisateurs créés par Amazon EKS](default-roles-users.md)
+ [Chiffrer les secrets Kubernetes avec KMS sur les clusters existants](enable-kms.md)
+ [Utilisation des secrets AWS Secrets Manager avec Amazon EKS Pods](manage-secrets.md)
+ [Chiffrement d’enveloppe par défaut pour toutes les données de l’API Kubernetes](envelope-encryption.md)
# Sécurisation des charges de travail grâce aux certificats Kubernetes
L’API Kubernetes Certificates automatise le provisionnement des informations d’identification [X.509](https://www.itu.int/rec/T-REC-X.509). Elle dispose d’une interface de ligne de commande permettant aux clients de l’API Kubernetes de demander et d’obtenir des [certificats X.509](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/) auprès d’une autorité de certification (CA). Vous pouvez utiliser la ressource `CertificateSigningRequest` (CSR) pour demander à un signataire désigné de signer le certificat. Vos demandes sont approuvées ou refusées avant d’être signées. Kubernetes prend en charge à la fois les signataires intégrés et les signataires personnalisés, avec des comportements clairement définis. De cette façon, les clients peuvent prédire ce qu'il advient de leurs CSR. Pour en savoir plus sur la signature des certificats, consultez les [demandes de signature](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/).
L'un des signataires intégrés est `kubernetes.io/legacy-unknown`. L'API `v1beta1` de la ressource CSR a honoré ce signataire d'héritage inconnu. Cependant, l’API `v1` stable de CSR ne permet pas de définir `signerName` sur `kubernetes.io/legacy-unknown`.
Si vous souhaitez utiliser Amazon EKS CA pour générer des certificats sur vos clusters, vous devez utiliser un signataire personnalisé. Pour utiliser la version de l'API CSR `v1` et générer un nouveau certificat, vous devez migrer tous les manifestes et clients API existants. Les certificats existants créés avec l'API `v1beta1` existante sont valides et fonctionnent jusqu'à l'expiration du certificat. Cela inclut les éléments suivants :
+ Distribution d'approbation : aucune. Il n’existe pas d’approbation ou de distribution standard pour ce signataire dans un cluster Kubernetes.
+ Sujets autorisés : tous
+ Extensions x509 autorisées : honore SubjectAltName et les extensions d'utilisation des clés et rejette les autres extensions
+ Utilisations de clés autorisées : ne doit pas inclure les utilisations au-delà de [« chiffrement de clé », « signature numérique », « authentification du serveur »]
**Note**
La signature de certificat client n'est pas prise en charge.
+ Expiration/durée de vie du certificat : 1 an (par défaut et maximum)
+ Bit CA autorisé/interdit : non autorisé
## Exemple de génération CSR avec SignerName
Ces étapes montrent comment générer un certificat de service pour un nom DNS `myserver.default.svc` en utilisant `signerName: beta.eks.amazonaws.com/app-serving`. Utilisez-le comme guide pour votre propre environnement.
1. Exécutez la commande `openssl genrsa -out myserver.key 2048` pour générer une clé privée RSA.
```
openssl genrsa -out myserver.key 2048
```
1. Utilisez la commande suivante pour générer une demande de certificat.
```
openssl req -new -key myserver.key -out myserver.csr -subj "/CN=myserver.default.svc"
```
1. Générez une valeur `base64` pour la demande CSR et stockez-la dans une variable, car vous en aurez besoin lors d'une étape ultérieure.
```
base_64=$(cat myserver.csr | base64 -w 0 | tr -d "
")
```
1. Pour créer un fichier nommé `mycsr.yaml`, exécutez la commande suivante. Dans l'exemple suivant, `beta.eks.amazonaws.com/app-serving` est le `signerName`.
```
cat >mycsr.yaml < myserver.crt
```
# Comprendre les rôles RBAC et les utilisateurs créés par Amazon EKS
Lorsque vous créez un cluster Kubernetes, plusieurs identités Kubernetes par défaut sont créées sur ce cluster afin d’assurer le bon fonctionnement de Kubernetes. Amazon EKS crée des identités Kubernetes pour chacun de ses composants par défaut. Les identités fournissent un contrôle d’autorisation basé sur les rôles (RBAC) Kubernetes pour les composants du cluster. Pour plus d'informations, consultez [Utilisation de l'autorisation RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) dans la documentation Kubernetes.
Lorsque vous installez des [modules complémentaires](eks-add-ons.md) optionnels sur votre cluster, des identités Kubernetes supplémentaires peuvent être ajoutées à votre cluster. Pour plus d'informations sur les identités non abordées dans cette rubrique, consultez la documentation du module complémentaire.
Vous pouvez consulter la liste des identités Kubernetes créées par Amazon EKS sur votre cluster à l'aide de l'outil de ligne de `kubectl` commande AWS Management Console or. Toutes les identités des utilisateurs apparaissent dans les journaux `kube` d'audit mis à votre disposition via Amazon CloudWatch.
## AWS Management Console
### Prérequis
Le [principal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que vous utilisez doit disposer des autorisations décrites dans la section [Autorisations requises](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
### Pour consulter les identités créées par Amazon EKS à l'aide du AWS Management Console
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 identités que vous souhaitez afficher.
1. Sélectionnez l'onglet **Ressources**.
1. Sous **Resource types** (Types de ressources), sélectionnez **Authorization** (Autorisation).
1. Choisissez, **ClusterRoles**ClusterRoleBindings****, **Rôles** ou **RoleBindings**. Toutes les ressources précédées de **eks** sont créées par Amazon EKS. Les ressources d'identité supplémentaires créées par Amazon EKS sont les suivantes :
+ Le **ClusterRole**et **ClusterRoleBinding**nommé **aws-node**. Les ressources **aws-node** prennent en charge le plug-in [Amazon VPC CNI pour Kubernetes](managing-vpc-cni.md), qu’Amazon EKS installe sur tous les clusters.
+ Un **ClusterRole**nom **vpc-resource-controller-role**et un **ClusterRoleBinding**nom **vpc-resource-controller-rolebinding**. Ces ressources prennent en charge le [contrôleur de ressources Amazon VPC](https://github.com/aws/amazon-vpc-resource-controller-k8s), qu'Amazon EKS installe sur tous les clusters.
Outre les ressources que vous voyez dans la console, les identités utilisateur spéciales suivantes existent sur votre cluster, bien qu’elles ne soient pas visibles dans la configuration du cluster :
+ ** `eks:cluster-bootstrap` ** : utilisé pour les opérations `kubectl` pendant le démarrage du cluster.
+ ** `eks:support-engineer` ** : utilisée pour les opérations de gestion des clusters.
1. Choisissez une ressource spécifique pour afficher les détails la concernant. Par défaut, les informations s’affichent en mode **Structured view (Vue structurée)**. Dans le coin supérieur droit de la page de détails, vous pouvez sélectionner **Raw view** (Vue brute) pour afficher toutes les informations relative à la ressource.
## Kubectl
### Prérequis
L'entité que vous utilisez (AWS Identity and Access Management (IAM) ou OpenID Connect (OIDC)) pour répertorier les ressources Kubernetes du cluster doit être authentifiée par IAM ou par votre fournisseur d'identité OIDC. L’entité doit disposer des autorisations nécessaires pour utiliser Kubernetes `get` et les verbes `list` pour les ressources `Role`, `ClusterRole`, `RoleBinding`, et `ClusterRoleBinding` de votre cluster avec lesquelles vous souhaitez que l’entité fonctionne. Pour plus d'informations sur la façon dont vous pouvez autoriser votre cluster à accéder aux entités IAM, consultez [Accorder aux utilisateurs et aux rôles IAM l'accès à Kubernetes APIs](grant-k8s-access.md). Pour plus d’informations sur l’octroi à des entités authentifiées par votre propre fournisseur OIDC d’un accès à votre cluster, consultez [Accès des utilisateurs à Kubernetes via un fournisseur OIDC externe](authenticate-oidc-identity-provider.md).
### Pour consulter les identités créées par Amazon EKS à l'aide de `kubectl`
Exécutez la commande correspondant au type de ressource que vous souhaitez consulter. Toutes les ressources renvoyées qui sont précédées de **eks** sont créées par Amazon EKS. Outre les ressources renvoyées dans la sortie des commandes, les identités d’utilisateur spéciales suivantes sont disponibles sur votre cluster, même si elles n’apparaissent pas dans la configuration du cluster :
+ ** `eks:cluster-bootstrap` ** : utilisé pour les opérations `kubectl` pendant le démarrage du cluster.
+ ** `eks:support-engineer` ** : utilisée pour les opérations de gestion des clusters.
**ClusterRoles**— `ClusterRoles` sont limités à votre cluster, de sorte que toute autorisation accordée à un rôle s'applique aux ressources de n'importe quel espace de noms Kubernetes du cluster.
La commande suivante renvoie tous les `ClusterRoles` Kubernetes créés par Amazon EKS sur votre cluster.
```
kubectl get clusterroles | grep eks
```
Outre les `ClusterRoles` renvoyés dans la sortie, les `ClusterRoles` suivants sont disponibles.
+ ** `aws-node` ** : ce `ClusterRole` prend en charge le plug-in [Amazon VPC CNI pour Kubernetes](managing-vpc-cni.md), qu’Amazon EKS installe sur tous les clusters.
+ ** `vpc-resource-controller-role` ** : ce `ClusterRole` prend en charge le [contrôleur de ressources Amazon VPC](https://github.com/aws/amazon-vpc-resource-controller-k8s), qu’Amazon EKS installe sur tous les clusters.
Pour voir la spécification de a`ClusterRole`, remplacez *eks:k8s-metrics* la commande suivante par un `ClusterRole` renvoyé dans la sortie de la commande précédente. L'exemple suivant renvoie la spécification du *eks:k8s-metrics*`ClusterRole`.
```
kubectl describe clusterrole eks:k8s-metrics
```
L'exemple qui suit illustre un résultat.
```
Name: eks:k8s-metrics
Labels:
Annotations:
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
[/metrics] [] [get]
endpoints [] [] [list]
nodes [] [] [list]
pods [] [] [list]
deployments.apps [] [] [list]
```
**ClusterRoleBindings**— `ClusterRoleBindings` sont limités à votre cluster.
La commande suivante renvoie tous les Kubernetes `ClusterRoleBindings` créés par Amazon EKS sur votre cluster.
```
kubectl get clusterrolebindings | grep eks
```
En plus des `ClusterRoleBindings` renvoyés dans la sortie, les `ClusterRoleBindings` suivants sont disponibles.
+ ** `aws-node` ** : ce `ClusterRoleBinding` prend en charge le plug-in [Amazon VPC CNI pour Kubernetes](managing-vpc-cni.md), qu’Amazon EKS installe sur tous les clusters.
+ ** `vpc-resource-controller-rolebinding` ** : ce `ClusterRoleBinding` prend en charge le [contrôleur de ressources Amazon VPC](https://github.com/aws/amazon-vpc-resource-controller-k8s), qu’Amazon EKS installe sur tous les clusters.
Pour voir la spécification de a`ClusterRoleBinding`, remplacez *eks:k8s-metrics* la commande suivante par un `ClusterRoleBinding` renvoyé dans la sortie de la commande précédente. L'exemple suivant renvoie la spécification du *eks:k8s-metrics*`ClusterRoleBinding`.
```
kubectl describe clusterrolebinding eks:k8s-metrics
```
L'exemple qui suit illustre un résultat.
```
Name: eks:k8s-metrics
Labels:
Annotations:
Role:
Kind: ClusterRole
Name: eks:k8s-metrics
Subjects:
Kind Name Namespace
---- ---- ---------
User eks:k8s-metrics
```
**Rôles** : les `Roles` sont limités à un espace de noms Kubernetes. Tous les `Roles` créés par Amazon EKS sont limités à l'espace de noms `kube-system`.
La commande suivante renvoie tous les Kubernetes `Roles` créés par Amazon EKS sur votre cluster.
```
kubectl get roles -n kube-system | grep eks
```
Pour voir la spécification de a`Role`, remplacez *eks:k8s-metrics* la commande suivante par le nom de a `Role` renvoyé dans le résultat de la commande précédente. L'exemple suivant renvoie la spécification du *eks:k8s-metrics*`Role`.
```
kubectl describe role eks:k8s-metrics -n kube-system
```
L'exemple qui suit illustre un résultat.
```
Name: eks:k8s-metrics
Labels:
Annotations:
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
daemonsets.apps [] [aws-node] [get]
deployments.apps [] [vpc-resource-controller] [get]
```
**RoleBindings**— `RoleBindings` sont limités à un espace de noms Kubernetes. Tous les `RoleBindings` créés par Amazon EKS sont limités à l'espace de noms `kube-system`.
La commande suivante renvoie tous les Kubernetes `RoleBindings` créés par Amazon EKS sur votre cluster.
```
kubectl get rolebindings -n kube-system | grep eks
```
Pour voir la spécification de a`RoleBinding`, remplacez *eks:k8s-metrics* la commande suivante par un `RoleBinding` renvoyé dans la sortie de la commande précédente. L'exemple suivant renvoie la spécification du *eks:k8s-metrics*`RoleBinding`.
```
kubectl describe rolebinding eks:k8s-metrics -n kube-system
```
L'exemple qui suit illustre un résultat.
```
Name: eks:k8s-metrics
Labels:
Annotations:
Role:
Kind: Role
Name: eks:k8s-metrics
Subjects:
Kind Name Namespace
---- ---- ---------
User eks:k8s-metrics
```
# Chiffrer les secrets Kubernetes avec KMS sur les clusters existants
**Important**
Cette procédure s’applique uniquement aux clusters EKS exécutant Kubernetes version 1.27 ou antérieure. Si vous utilisez Kubernetes version 1.28 ou supérieure, vos secrets Kubernetes sont protégés par défaut par un chiffrement par enveloppe. Pour de plus amples informations, veuillez consulter [Chiffrement d’enveloppe par défaut pour toutes les données de l’API Kubernetes](envelope-encryption.md).
Si vous activez le [chiffrement des secrets](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/), les secrets Kubernetes sont chiffrés à l'aide de la clé AWS KMS que vous sélectionnez. La clé KMS doit répondre aux conditions suivantes :
+ Symétrique
+ Peut chiffrer et déchiffrer des données
+ Créé dans la même AWS région que le cluster
+ Si la clé KMS a été créée dans un autre compte, le [principal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) doit avoir accès à la clé KMS.
Pour plus d'informations, consultez la section [Autoriser les principaux IAM d'autres comptes à utiliser une clé KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html) dans le Guide du *[développeur du service de gestion des AWS clés](https://docs.aws.amazon.com/kms/latest/developerguide/)*.
**Avertissement**
Vous ne pouvez pas désactiver le chiffrement des secrets après l’avoir activé. Cette action est irréversible.
eksctl
Cette procédure s’applique uniquement aux clusters EKS exécutant Kubernetes version 1.27 ou antérieure. Pour de plus amples informations, veuillez consulter [Chiffrement d’enveloppe par défaut pour toutes les données de l’API Kubernetes](envelope-encryption.md).
Vous pouvez activer le chiffrement de deux manières :
+ Ajoutez le chiffrement à votre cluster à l'aide d'une seule commande.
Pour re-chiffrer automatiquement vos secrets, exécutez la commande suivante.
```
eksctl utils enable-secrets-encryption \
--cluster my-cluster \
--key-arn arn:aws: kms:region-code:account:key/key
```
Pour vous désabonner du chiffrement automatique de vos secrets, exécutez la commande suivante.
```
eksctl utils enable-secrets-encryption
--cluster my-cluster \
--key-arn arn:aws: kms:region-code:account:key/key \
--encrypt-existing-secrets=false
```
+ Ajoutez le chiffrement à votre cluster à l'aide d'un fichier `kms-cluster.yaml`.
```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: region-code
secretsEncryption:
keyARN: arn:aws: kms:region-code:account:key/key
```
Pour re-chiffrer automatiquement vos secrets, exécutez la commande suivante.
```
eksctl utils enable-secrets-encryption -f kms-cluster.yaml
```
Pour vous désabonner du chiffrement automatique de vos secrets, exécutez la commande suivante.
```
eksctl utils enable-secrets-encryption -f kms-cluster.yaml --encrypt-existing-secrets=false
```
AWS Management Console
1. Cette procédure s’applique uniquement aux clusters EKS exécutant Kubernetes version 1.27 ou antérieure. Pour de plus amples informations, veuillez consulter [Chiffrement d’enveloppe par défaut pour toutes les données de l’API Kubernetes](envelope-encryption.md).
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Choisissez le cluster auquel vous souhaitez ajouter le chiffrement KMS.
1. Cliquez sur l'onglet **Présentation** (cette option est sélectionnée par défaut).
1. Faites défiler la page jusqu'à **Secrets encryption** (Chiffrement des secrets) et sélectionnez **Enable** (Activer).
1. Sélectionnez une clé dans la liste déroulant et appuyez sur le bouton **Enable** (Activer). Si aucune clé n'est répertoriée, vous devez d'abord en créer une. Pour plus d'informations, consultez [Création de clés](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html).
1. Appuyez sur le bouton **Confirm** (Confirmer) pour utiliser la touche choisie.
AWS CLI
1. Cette procédure s’applique uniquement aux clusters EKS exécutant Kubernetes version 1.27 ou antérieure. Pour de plus amples informations, veuillez consulter [Chiffrement d’enveloppe par défaut pour toutes les données de l’API Kubernetes](envelope-encryption.md).
1. Associez la configuration de [chiffrement des secrets](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) à votre cluster à l'aide de la commande AWS CLI suivante. Remplacez les exemples de valeurs par les vôtres.
```
aws eks associate-encryption-config \
--cluster-name my-cluster \
--encryption-config '[{"resources":["secrets"],"provider":{"keyArn":"arn:aws: kms:region-code:account:key/key"}}]'
```
L'exemple qui suit illustre un résultat.
```
{
"update": {
"id": "3141b835-8103-423a-8e68-12c2521ffa4d",
"status": "InProgress",
"type": "AssociateEncryptionConfig",
"params": [
{
"type": "EncryptionConfig",
"value": "[{\"resources\":[\"secrets\"],\"provider\":{\"keyArn\":\"arn:aws: kms:region-code:account:key/key\"}}]"
}
],
"createdAt": 1613754188.734,
"errors": []
}
}
```
1. Vous pouvez contrôler l'état de votre mise à jour de chiffrement à l'aide de la commande suivante. Utilisez le `cluster name` et le `update ID` spécifiques qui ont été renvoyés dans la sortie précédente. Lorsqu'un état `Successful` s'affiche, la mise à jour est terminée.
```
aws eks describe-update \
--region region-code \
--name my-cluster \
--update-id 3141b835-8103-423a-8e68-12c2521ffa4d
```
L'exemple qui suit illustre un résultat.
```
{
"update": {
"id": "3141b835-8103-423a-8e68-12c2521ffa4d",
"status": "Successful",
"type": "AssociateEncryptionConfig",
"params": [
{
"type": "EncryptionConfig",
"value": "[{\"resources\":[\"secrets\"],\"provider\":{\"keyArn\":\"arn:aws: kms:region-code:account:key/key\"}}]"
}
],
"createdAt": 1613754188.734>,
"errors": []
}
}
```
1. Pour vérifier que le chiffrement est activé dans votre cluster, exécutez la commande `describe-cluster`. La réponse contient une chaîne `EncryptionConfig`.
```
aws eks describe-cluster --region region-code --name my-cluster
```
Une fois que vous avez activé le chiffrement sur votre cluster, vous devez chiffrer tous les secrets existants avec la nouvelle clé :
**Note**
Si vous utilisez `eksctl`, l'exécution de la commande suivante n'est nécessaire que si vous vous désabonnez du chiffrement automatique de vos secrets.
```
kubectl get secrets --all-namespaces -o json | kubectl annotate --overwrite -f - kms-encryption-timestamp="time value"
```
**Avertissement**
Si vous activez le [chiffrement de secrets](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) pour un cluster existant et que la clé KMS que vous utilisez est supprimée, il n’y a pas de chemin vers la récupération pour le cluster. Si vous supprimez la clé KMS, vous mettez définitivement le cluster dans un état dégradé. Pour plus d'informations, consultez la section [Suppression de clés AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html).
**Note**
Par défaut, la `create-key` commande crée une [clé KMS de chiffrement symétrique](https://docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html) avec une politique de clé qui donne à l'administrateur racine du compte un accès aux actions et aux ressources AWS KMS. Si vous souhaitez limiter les autorisations, assurez-vous que les actions `kms:DescribeKey` et `kms:CreateGrant` sont autorisées sur la stratégie pour le principal qui appellera l'API `create-cluster`.
Pour les clusters utilisant le chiffrement d'enveloppe KMS, des autorisations `kms:CreateGrant` sont requises. La condition n'`kms:GrantIsForAWSResource`est pas prise en charge pour l' CreateCluster action et ne doit pas être utilisée dans les politiques KMS pour contrôler `kms:CreateGrant` les autorisations accordées aux utilisateurs CreateCluster.
# Utilisation des secrets AWS Secrets Manager avec Amazon EKS Pods
Pour afficher les secrets du gestionnaire de secrets et les paramètres du magasin de paramètres sous forme de fichiers montés dans les pods Amazon EKS, vous pouvez utiliser le fournisseur de secrets et de configuration AWS (ASCP) pour le [pilote CSI du magasin de secrets Kubernetes](https://secrets-store-csi-driver.sigs.k8s.io/).
Avec l'ASCP, vous pouvez stocker et gérer vos secrets dans Secrets Manager, puis les récupérer via vos applications exécutées sur Amazon EKS. Vous pouvez utiliser des rôles et des stratégies IAM pour limiter l’accès à vos secrets à des pods Kubernetes spécifiques dans un cluster. L’ASCP récupère l’identité du pod et l’échange contre un rôle IAM. ASCP assume le rôle IAM du pod, puis il peut récupérer les secrets de Secrets Manager autorisés pour ce rôle.
Si vous utilisez la rotation automatique de Secrets Manager pour vos secrets, vous pouvez également utiliser la fonction de réconciliation de rotation du pilote CSI de Secrets Store pour vous assurer que vous récupérez le dernier secret de Secrets Manager.
**Note**
Les groupes de nœuds AWS Fargate (Fargate) ne sont pas pris en charge.
Pour plus d'informations, consultez [Utilisation des secrets de Secrets Manager dans Amazon EKS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_csi_driver.html) dans le Guide de l'utilisateur AWS Secrets Manager.
# Chiffrement d’enveloppe par défaut pour toutes les données de l’API Kubernetes
Amazon Elastic Kubernetes Service (Amazon EKS) fournit un chiffrement par défaut pour toutes les données API Kubernetes dans les clusters EKS exécutant la version 1.28 ou supérieure de Kubernetes.
Le chiffrement des enveloppes protège les données que vous stockez avec le serveur d’API Kubernetes. Par exemple, le chiffrement d’enveloppe s’applique à la configuration de votre cluster Kubernetes, par exemple `ConfigMaps`. Le chiffrement des enveloppes ne s’applique pas aux données des nœuds ou des volumes EBS. EKS prenait déjà en charge le chiffrement des secrets Kubernetes, et désormais, ce chiffrement par enveloppe s’étend à toutes les données API Kubernetes.
Cela fournit une expérience gérée par défaut qui s'implémente defense-in-depth pour vos applications Kubernetes et ne nécessite aucune action de votre part.
Amazon EKS utilise le [service de gestion des AWS clés (KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) avec le [fournisseur Kubernetes KMS v2](https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/#configuring-the-kms-provider-kms-v2) pour cette couche de sécurité supplémentaire avec une [clé appartenant à Amazon Web Services](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) et la possibilité pour vous d'apporter votre propre [clé gérée par le client](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) (CMK) auprès de KMS. AWS
## Comprendre le chiffrement d’enveloppe
Le chiffrement d'enveloppe consiste à chiffrer des données en texte brut à l'aide d'une clé de chiffrement des données (DEK) avant leur envoi à la banque de données (etcd), puis à chiffrer la DEK avec une clé KMS racine stockée dans un système KMS (KMS) distant géré de manière centralisée (KMS).AWS Il s'agit d'une defense-in-depth stratégie car elle protège les données à l'aide d'une clé de chiffrement (DEK), puis ajoute une autre couche de sécurité en protégeant cette DEK avec une clé de chiffrement séparée et stockée de manière sécurisée appelée clé de chiffrement (KEK).
## Comment Amazon EKS active le chiffrement des enveloppes par défaut avec KMS v2 et AWS KMS
Amazon EKS utilise [KMS v2](https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/#kms-v2) pour mettre en œuvre le chiffrement par défaut de toutes les données API dans le plan de contrôle Kubernetes géré avant leur conservation dans la base de données [etcd](https://etcd.io/docs/v3.5/faq/). Au démarrage, le serveur API du cluster génère une clé de chiffrement des données (DEK) à partir d’une graine secrète combinée à des données générées aléatoirement. Au démarrage également, le serveur d'API appelle le plug-in KMS pour chiffrer le seed DEK à l'aide d'une clé de chiffrement par clé distante (KEK) fournie par AWS KMS. Il s’agit d’un appel ponctuel exécuté au démarrage du serveur API et lors de la rotation du KEK. Le serveur API met ensuite en cache la graine DEK chiffrée. Ensuite, le serveur API utilise la graine DEK mise en cache pour générer d'autres données à usage unique DEKs basées sur une fonction de dérivation de clés (KDF). Chacun de ces éléments générés n' DEKs est ensuite utilisé qu'une seule fois pour chiffrer une seule ressource Kubernetes avant qu'elle ne soit stockée dans etcd. Grâce à l’utilisation d’une graine DEK cryptée mise en cache dans KMS v2, le processus de cryptage des ressources Kubernetes dans le serveur API est à la fois plus performant et plus rentable.
**Par défaut, ce KEK appartient à AWS KMS AWS, mais vous pouvez éventuellement apporter le vôtre.**
Le schéma ci-dessous décrit la génération et le chiffrement d’un DEK au démarrage du serveur d’API.
![\[Le schéma décrit la génération et le chiffrement d’un DEK au démarrage du serveur d’API\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/security-generate-dek.png)
Le schéma de haut niveau ci-dessous décrit le chiffrement d’une ressource Kubernetes avant son stockage dans etcd.
![\[Le diagramme de haut niveau décrit le chiffrement d’une ressource Kubernetes avant son stockage dans etcd.\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/security-encrypt-request.png)
## Questions fréquentes (FAQ)
### Comment le chiffrement d’enveloppe par défaut améliore-t-il le niveau de sécurité de mon cluster EKS ?
Cette fonctionnalité réduit la surface et la durée pendant lesquelles les métadonnées et le contenu client ne sont pas cryptés. Avec le chiffrement par défaut des enveloppes, les métadonnées et le contenu client ne sont temporairement déchiffrés que dans la mémoire du kube-apiserver avant d’être stockés dans etcd. [La mémoire du kube-apiserver est sécurisée via le système Nitro.](https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/the-components-of-the-nitro-system.html) Amazon EKS utilise uniquement des [instances EC2 basées sur Nitro](https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/security-design-of-aws-nitro-system.html) pour le plan de contrôle Kubernetes géré. Ces instances sont dotées de dispositifs de contrôle de sécurité qui empêchent tout système ou toute personne d’accéder à leur mémoire.
### Quelle version de Kubernetes dois-je exécuter pour bénéficier de cette fonctionnalité ?
Pour que le chiffrement par défaut des enveloppes soit activé, votre cluster Amazon EKS doit exécuter Kubernetes version 1.28 ou ultérieure.
### Mes données sont-elles toujours sécurisées si j’utilise une version de cluster Kubernetes qui ne prend pas en charge cette fonctionnalité ?
Oui. Chez AWS, [la sécurité est notre priorité absolue](https://aws.amazon.com/security/). Nous basons toute notre transformation numérique et notre innovation sur les pratiques opérationnelles les plus strictes en matière de sécurité, et nous nous engageons à relever encore davantage la barre.
Toutes les données stockées dans etcd sont chiffrées au niveau du disque pour chaque cluster EKS, quelle que soit la version de Kubernetes utilisée. EKS utilise des clés racines qui génèrent des clés de chiffrement de volume gérées par le service EKS. De plus, chaque cluster Amazon EKS est exécuté dans un VPC isolé à l’aide de machines virtuelles spécifiques au cluster. Grâce à cette architecture et à nos pratiques en matière de sécurité opérationnelle, Amazon EKS a [obtenu plusieurs certifications et normes de conformité](https://docs.aws.amazon.com/eks/latest/userguide/compliance.html), notamment SOC 1, 2 et 3, PCI-DSS, ISO et HIPAA. Ces notes et normes de conformité sont maintenues pour tous les clusters EKS, avec ou sans chiffrement d’enveloppe par défaut.
### Comment fonctionne le chiffrement des enveloppes dans Amazon EKS ?
Au démarrage, le serveur API du cluster génère une clé de chiffrement des données (DEK) à partir d’une graine secrète combinée à des données générées aléatoirement. Au démarrage également, le serveur d'API appelle le plug-in KMS pour chiffrer le DEK à l'aide d'une clé de chiffrement à distance (KEK) fournie par AWS KMS. Il s’agit d’un appel ponctuel exécuté au démarrage du serveur API et lors de la rotation du KEK. Le serveur API met ensuite en cache la graine DEK chiffrée. Ensuite, le serveur API utilise la graine DEK mise en cache pour générer d'autres données à usage unique DEKs basées sur une fonction de dérivation de clés (KDF). Chacun de ces éléments générés n' DEKs est ensuite utilisé qu'une seule fois pour chiffrer une seule ressource Kubernetes avant qu'elle ne soit stockée dans etcd.
Il est important de noter que des appels supplémentaires sont effectués depuis le serveur API pour vérifier le bon fonctionnement et le fonctionnement normal de l'intégration AWS KMS. Ces bilans de santé supplémentaires sont visibles dans votre AWS CloudTrail.
### Dois-je effectuer une action ou modifier des autorisations pour que cette fonctionnalité fonctionne dans mon cluster EKS ?
Non, vous n’avez aucune démarche à effectuer. Le chiffrement des enveloppes dans Amazon EKS est désormais une configuration par défaut activée dans tous les clusters exécutant Kubernetes version 1.28 ou supérieure. L'intégration AWS KMS est établie par le serveur d'API Kubernetes géré par. AWS Cela signifie que vous n’avez pas besoin de configurer d’autorisations pour commencer à utiliser le chiffrement KMS pour votre cluster.
### Comment savoir si le chiffrement d’enveloppe par défaut est activé sur mon cluster ?
Si vous migrez pour utiliser votre propre CMK, vous verrez alors l’ARN de la clé KMS associée à votre cluster. En outre, vous pouvez consulter les journaux AWS CloudTrail d'événements associés à l'utilisation de la clé CMK de votre cluster.
Si votre cluster utilise une clé AWS détenue, celle-ci sera détaillée dans la console EKS (à l'exception de l'ARN de la clé).
### Puis-je AWS accéder à la clé AWS détenue utilisée pour le chiffrement des enveloppes par défaut dans Amazon EKS ?
Non AWS dispose de contrôles de sécurité stricts dans Amazon EKS qui empêchent toute personne d'accéder aux clés de chiffrement en texte brut utilisées pour sécuriser les données de la base de données etcd. Ces mesures de sécurité sont également appliquées à la clé KMS AWS détenue.
### Le chiffrement d’enveloppe par défaut est-il activé dans mon cluster EKS existant ?
Si vous utilisez un cluster Amazon EKS avec la version 1.28 ou supérieure de Kubernetes, le chiffrement par enveloppe de toutes les données API Kubernetes est activé. Pour les clusters existants, Amazon EKS utilise le `eks:kms-storage-migrator` RBAC ClusterRole pour faire migrer les données qui n'étaient pas auparavant chiffrées par enveloppe dans etcd vers ce nouvel état de chiffrement.
### Qu’est-ce que cela signifie si j’ai déjà activé le chiffrement par enveloppe pour les secrets dans mon cluster EKS ?
Si vous disposez déjà d’une clé gérée par le client (CMK) dans KMS qui a été utilisée pour crypter vos secrets Kubernetes, cette même clé sera utilisée comme KEK pour le cryptage de tous les types de données API Kubernetes dans votre cluster.
### Y a-t-il un coût supplémentaire pour l’exécution d’un cluster EKS avec le chiffrement par défaut des enveloppes ?
Il n’y a pas de coût supplémentaire associé au plan de contrôle Kubernetes géré si vous utilisez une [clé appartenant à Amazon Web Services](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) pour le chiffrement par défaut des enveloppes. Par défaut, chaque cluster EKS exécutant Kubernetes version 1.28 ou ultérieure utilise une [clé appartenant à Amazon Web Service](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk). Toutefois, si vous utilisez votre propre clé AWS KMS, la [tarification KMS](https://aws.amazon.com/kms/pricing/) normale s'appliquera.
### Combien coûte l'utilisation de ma propre clé AWS KMS pour chiffrer les données de l'API Kubernetes dans mon cluster ?
Vous payez 1\$1 par mois pour stocker toute clé personnalisée que vous créez ou importez dans KMS. KMS facture les demandes de chiffrement et de déchiffrement. Il existe un forfait gratuit de 20 000 requêtes par mois et par compte. Au-delà de ce forfait gratuit, vous payez 0,03 \$1 par tranche de 10 000 requêtes supplémentaires par mois. Cela s'applique à toutes les utilisations de KMS pour un compte, de sorte que le coût d'utilisation de votre propre clé AWS KMS sur votre cluster sera affecté par l'utilisation de cette clé sur d'autres clusters ou AWS ressources de votre compte.
### Mes frais KMS seront-ils plus élevés maintenant que ma clé gérée par le client (CMK) est utilisée pour crypter toutes les données API Kubernetes et pas seulement les secrets ?
Non Notre mise en œuvre avec KMS v2 réduit considérablement le nombre d'appels passés à AWS KMS. Cela permettra à son tour de réduire les coûts associés à votre CMK, indépendamment des données Kubernetes supplémentaires cryptées ou décryptées dans votre cluster EKS.
Comme indiqué ci-dessus, la clé DEK générée utilisée pour le chiffrement des ressources Kubernetes est stockée localement dans le cache du serveur API Kubernetes après avoir été chiffrée avec la clé KEK distante. Si la graine DEK chiffrée ne se trouve pas dans le cache du serveur API, le serveur API appellera AWS KMS pour chiffrer la graine DEK. Le serveur API met ensuite en cache la graine DEK chiffrée pour une utilisation future dans le cluster sans appeler KMS. De même, pour les demandes de déchiffrement, le serveur API appellera AWS KMS pour la première demande de déchiffrement, après quoi la graine DEK déchiffrée sera mise en cache et utilisée pour les futures opérations de déchiffrement.
Pour plus d'informations, consultez [KEP-3299 : Améliorations de KMS v2 dans les améliorations](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/3299-kms-v2-improvements) de Kubernetes sur. GitHub
### Puis-je utiliser la même clé CMK pour plusieurs clusters Amazon EKS ?
Oui. Pour réutiliser une clé, vous pouvez la lier à un cluster dans la même région en associant l’ARN au cluster lors de sa création. Toutefois, si vous utilisez la même CMK pour plusieurs clusters EKS, vous devez mettre en place les mesures nécessaires pour empêcher la désactivation arbitraire de la CMK. Sinon, une CMK désactivée associée à plusieurs clusters EKS aura un impact plus large sur les clusters en fonction de cette clé.
### Qu’arrive-t-il à mon cluster EKS si ma clé CMK devient indisponible après l’activation du chiffrement d’enveloppe par défaut ?
Si vous désactivez une clé KMS, celle-ci ne peut plus être utilisée dans aucune [opération cryptographique](https://docs.aws.amazon.com/kms/latest/developerguide/kms-cryptography.html#cryptographic-operations). Sans accès à une CMK existante, le serveur API ne pourra pas chiffrer et conserver les objets Kubernetes nouvellement créés, ni déchiffrer les objets Kubernetes précédemment chiffrés stockés dans etcd. Si la clé CMK est désactivée, le cluster sera immédiatement placé dans un unhealthy/degraded état tel que nous ne serons pas en mesure de respecter notre [engagement de service](https://aws.amazon.com/eks/sla/) tant que vous n'aurez pas réactivé la clé CMK associée.
Lorsqu’une CMK est désactivée, vous recevrez des notifications concernant la dégradation de l’état de votre cluster EKS et la nécessité de réactiver votre CMK dans les 30 jours suivant sa désactivation afin de garantir la restauration réussie de vos ressources du plan de contrôle Kubernetes.
### Comment protéger mon cluster EKS de l'impact d'une clé disabled/deleted CMK ?
Pour protéger vos clusters EKS contre un tel événement, vos administrateurs clés doivent gérer l’accès aux opérations clés KMS à l’aide de politiques IAM basées sur le principe du moindre privilège afin de réduire le risque de désactivation ou de suppression arbitraire des clés associées aux clusters EKS. De plus, vous pouvez configurer une [CloudWatch alarme](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys-creating-cloudwatch-alarm.html) pour être informé de l'état de votre CMK.
### Mon cluster EKS sera-t-il restauré si je réactive le CMK ?
Pour garantir la réussite de la restauration de votre cluster EKS, nous vous recommandons vivement de réactiver votre CMK dans les 30 jours suivant sa désactivation. Cependant, le succès de la restauration de votre cluster EKS dépendra également de la question de savoir s'il subit ou non des modifications perturbatrices de l'API en raison d'une mise à niveau automatique de Kubernetes qui peut avoir lieu alors que le cluster est dans un état. unhealthy/degraded
### Pourquoi mon cluster EKS est-il placé dans un unhealthy/degraded état après avoir désactivé le CMK ?
Le serveur API du plan de contrôle EKS utilise une clé DEK qui est cryptée et mise en cache dans la mémoire du serveur API pour chiffrer tous les objets pendant les create/update opérations avant qu'ils ne soient stockés dans etcd. Lorsqu’un objet existant est récupéré depuis etcd, le serveur API utilise la même clé DEK mise en cache et déchiffre l’objet de ressource Kubernetes. Si vous désactivez la CMK, le serveur API ne subira aucun impact immédiat grâce à la clé DEK mise en cache dans la mémoire du serveur API. Toutefois, lorsque l'instance du serveur d'API est redémarrée, elle ne possède pas de DEK en cache et devra appeler AWS KMS pour les opérations de chiffrement et de déchiffrement. Sans CMK, ce processus échouera avec un code d’erreur KMS\$1KEY\$1DISABLED, empêchant le serveur API de démarrer correctement.
### Qu’arrive-t-il à mon cluster EKS si je supprime mon CMK ?
La suppression de la clé CMK associée à votre cluster EKS dégradera son état de manière irréversible. Sans la clé CMK de votre cluster, le serveur API ne sera plus en mesure de chiffrer et de conserver les nouveaux objets Kubernetes, ni de déchiffrer les objets Kubernetes précédemment chiffrés stockés dans la base de données etcd. Vous ne devez supprimer une clé CMK pour votre cluster EKS que lorsque vous êtes certain de ne plus avoir besoin d’utiliser ce cluster.
Veuillez noter que si la CMK est introuvable (KMS\$1KEY\$1NOT\$1FOUND) ou si les autorisations pour la CMK associée à votre cluster sont révoquées (KMS\$1GRANT\$1REVOKED), votre cluster ne pourra pas être restauré. Pour plus d'informations sur l'état du cluster et les codes d'erreur, voir [État du cluster FAQs et codes d'erreur avec chemins de résolution](https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting.html#cluster-health-status).
### Vais-je quand même être débité pour un cluster degraded/unhealthy EKS parce que j'ai désactivé ou supprimé ma clé CMK ?
Oui. Bien que le plan de contrôle EKS ne soit pas utilisable en cas de désactivation d'une clé CMK, les ressources d'infrastructure dédiées allouées au cluster EKS AWS continueront d'être utilisées jusqu'à ce qu'il soit supprimé par le client. De plus, notre [engagement de service](https://aws.amazon.com/eks/sla/) ne s’appliquera pas dans une telle circonstance, car ce sera une action ou une inaction volontaire de la part du client qui empêchera le bon fonctionnement et l’état normal de votre cluster EKS.
### Mon cluster EKS peut-il être automatiquement mis à niveau lorsqu'il est dans un unhealthy/degraded état en raison d'une clé CMK désactivée ?
Oui. Toutefois, si votre cluster dispose d’une CMK désactivée, vous disposerez d’un délai de 30 jours pour la réactiver. Au cours de cette période de 30 jours, votre cluster Kubernetes ne sera pas automatiquement mis à niveau. Toutefois, si ce délai expire et que vous n’avez pas réactivé la CMK, le cluster sera automatiquement mis à niveau vers la version suivante (n\$11) bénéficiant d’un support standard, conformément au cycle de vie des versions Kubernetes dans EKS.
Nous vous recommandons vivement de réactiver rapidement une CMK désactivée dès que vous constatez qu’un cluster est affecté. Il est important de noter que, bien qu’EKS mette automatiquement à niveau ces clusters concernés, rien ne garantit qu’ils seront restaurés avec succès, en particulier si le cluster subit plusieurs mises à niveau automatiques, car cela peut entraîner des modifications de l’API Kubernetes et un comportement inattendu dans le processus de démarrage du serveur API.
### Puis-je utiliser un alias de clé KMS ?
Oui. Amazon EKS prend en charge [l’utilisation des alias de clés KMS](https://docs.aws.amazon.com/eks/latest/APIReference/API_EncryptionConfig.html#API_EncryptionConfig_Contents). Un alias est un nom convivial attribué à une [clé KMS Amazon Web Service](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys). Par exemple, un alias vous permet de faire référence à une clé KMS en tant que **my-key** au lieu de ** `1234abcd-12ab-34cd-56ef-1234567890ab` **.
### Puis-je toujours sauvegarder et restaurer les ressources de mon cluster à l’aide de ma propre solution de sauvegarde Kubernetes ?
Oui. Vous pouvez utiliser une solution de sauvegarde Kubernetes (comme [Velero](https://velero.io/)) pour la reprise après sinistre, la migration des données et la protection des données du cluster Kubernetes. Si vous utilisez une solution de sauvegarde Kubernetes qui accède aux ressources du cluster via le serveur API, toutes les données récupérées par l’application seront déchiffrées avant d’atteindre le client. Cela vous permettra de récupérer les ressources du cluster dans un autre cluster Kubernetes.
# Considérations de sécurité relatives au mode automatique Amazon EKS
Cette rubrique décrit l’architecture de sécurité, les mécanismes de contrôle et les meilleures pratiques appliqués dans le mode automatique Amazon EKS. À mesure que les organisations déploient des applications conteneurisées à grande échelle, le maintien d’une posture de sécurité solide devient de plus en plus complexe. Le mode automatique EKS met en œuvre des contrôles de sécurité automatisés et s’intègre aux services de sécurité AWS pour vous aider à protéger l’infrastructure de vos clusters, ainsi que vos charges de travail et vos données. Grâce à des fonctionnalités de sécurité intégrées, telles que la gestion obligatoire du cycle de vie des nœuds et le déploiement automatisé des correctifs, le mode automatique EKS vous aide à maintenir les meilleures pratiques de sécurité tout en réduisant la charge opérationnelle.
Avant d’aborder cette rubrique, assurez-vous d’être familier avec les concepts de base du mode automatique EKS et d’avoir consulté les prérequis pour l’activer sur vos clusters. Pour des informations générales sur la sécurité d’Amazon EKS, consultez [Sécurité dans Amazon EKS](security.md).
Le mode automatique Amazon EKS repose sur les fondations de sécurité existantes d’Amazon EKS tout en introduisant des contrôles de sécurité automatisés supplémentaires pour les instances gérées EC2.
## Sécurité et authentification de l’API
Le mode automatique Amazon EKS utilise les mécanismes de sécurité de la plateforme AWS afin de sécuriser et authentifier les appels à l’API Amazon EKS.
+ L’accès à l’API Kubernetes est protégé par des entrées d’accès EKS, qui s’intègrent aux identités IAM AWS.
+ Pour de plus amples informations, consultez [Attribution de l’accès Kubernetes aux utilisateurs IAM avec les entrées d’accès EKS](access-entries.md).
+ Les clients peuvent mettre en œuvre un contrôle d’accès granulaire au point de terminaison de l’API Kubernetes grâce à la configuration des entrées d’accès EKS.
## Sécurité du réseau
Le mode automatique Amazon EKS prend en charge plusieurs niveaux de sécurité réseau :
+ **Intégration VPC**
+ Fonctionne au sein de votre Amazon Virtual Private Cloud (VPC)
+ Prend en charge les configurations VPC personnalisées et les configurations de sous-réseaux
+ Permet un réseau privé entre les composants du cluster
+ Pour plus d’informations, consultez la section [Gestion des responsabilités en matière de sécurité pour Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/security.html)
+ **Politiques réseau**
+ Prise en charge native des politiques réseau Kubernetes
+ Possibilité de définir des règles de trafic réseau granulaires
+ Pour plus d’informations, consultez [Limitation du trafic des pods à l’aide des politiques réseau Kubernetes](cni-network-policy.md).
## Sécurité des instances EC2 gérées
Le mode automatique Amazon EKS exploite des instances EC2 gérées avec les contrôles de sécurité suivants :
### Sécurité EC2
+ Les instances gérées EC2 conservent les fonctionnalités de sécurité d’Amazon EC2.
+ Pour plus d’informations sur les instances gérées EC2, consultez la section [Sécurité dans Amazon EC2.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security.html)
### Gestion du cycle de vie des instances
Les instances gérées EC2 exploitées par le mode automatique EKS ont une durée de vie maximale de 21 jours. Le mode automatique Amazon EKS met automatiquement fin aux instances qui dépassent cette durée. Cette limite de cycle de vie permet d’éviter toute dérive de configuration et de maintenir une posture de sécurité solide.
### Protection des données
+ Le stockage des instances Amazon EC2 est chiffré. Il s’agit d’un stockage directement connecté à l’instance. Pour de plus amples informations, consultez la section [Protection des données dans Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html).
+ Le mode automatique EKS gère les volumes rattachés aux instances EC2 au moment de leur création, y compris les volumes racine et les volumes de données. Le mode automatique EKS ne gère pas entièrement les volumes EBS créés via les fonctionnalités de stockage persistant de Kubernetes.
### Gestion des correctifs
+ Le mode automatique Amazon EKS applique automatiquement les correctifs aux instances gérées.
+ Les correctifs incluent :
+ Mises à jour du système d'exploitation
+ Correctifs de sécurité
+ Composants du mode automatique Amazon EKS
**Note**
Les clients retiennent la responsabilité de la sécurisation et de la mise à jour des charges de travail exécutées sur ces instances.
### Contrôles d’accès
+ L’accès direct aux instances est restreint :
+ L’accès SSH n’est pas disponible.
+ L’accès via le gestionnaire de session (SSM) d’AWS Systems Manager n’est pas disponible.
+ Les opérations de gestion sont effectuées via l’API Amazon EKS et l’API Kubernetes.
## Gestion automatisée des ressources
Le mode automatique Amazon EKS ne gère pas entièrement les volumes Amazon Elastic Block Store (Amazon EBS) créés à l’aide des fonctionnalités de stockage persistant Kubernetes. Le mode automatique EKS ne gère pas non plus les équilibreurs de charge Elastic Load Balancer (ELB). Cependant, le mode automatique Amazon EKS automatise les tâches courantes liées à ces ressources.
### Sécurité du stockage
+ AWS recommande d’activer le chiffrement pour les volumes EBS provisionnés à l’aide des fonctionnalités de stockage persistant de Kubernetes. Pour de plus amples informations, consultez [Création d’une classe de stockage](create-storage-class.md).
+ Chiffrement au repos à l’aide d’AWS KMS
+ Vous pouvez configurer votre compte AWS pour imposer le chiffrement des nouveaux volumes EBS et des copies d’instantané que vous créez. Pour plus d’informations, consultez [Activation du chiffrement Amazon EBS par défaut](https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html) dans le Guide de l’utilisateur Amazon EBS.
+ Pour plus d’informations, consultez [Sécurité dans Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/security.html).
### Sécurité des équilibreurs de charge
+ Configuration automatisée des équilibreurs de charge Elastic Load Balancer
+ Gestion des certificats SSL/TLS par intégration à AWS Certificate Manager
+ Automatisation des groupes de sécurité pour le contrôle d’accès aux équilibreurs de charge
+ Pour plus d’informations, consultez [Sécurité dans Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/security.html).
## Bonnes pratiques de sécurité
La section suivante décrit les bonnes pratiques en matière de sécurité pour le mode automatique Amazon EKS.
+ Passez régulièrement en revue les politiques IAM AWS et les entrées d’accès EKS.
+ Mettez en œuvre le principe du moindre privilège pour les charges de travail.
+ Surveillez l’activité du cluster via AWS CloudTrail et Amazon CloudWatch. Pour plus d’informations, consultez [Journaliser les appels d’API en tant qu’événements AWS CloudTrail](logging-using-cloudtrail.md) et [Surveillez les données du cluster avec Amazon CloudWatch](cloudwatch.md).
+ Utilisez AWS Security Hub pour évaluer le niveau de sécurité.
+ Mettez en œuvre des normes de sécurité des pods adaptées aux charges de travail.
# Considérations relatives à la sécurité relatives aux fonctionnalités EKS
Cette rubrique aborde les principales considérations de sécurité relatives aux fonctionnalités EKS, notamment la configuration des rôles IAM, les autorisations Kubernetes et les modèles architecturaux pour les déploiements multi-clusters et la gestion des ressources entre comptes. AWS
Les fonctionnalités d'EKS utilisent une combinaison de rôles IAM, d'entrées d'accès EKS et de Kubernetes RBAC pour fournir un accès sécurisé aux AWS services, aux ressources Kubernetes du cluster et des intégrations avec Secrets Manager et d'autres services. AWS CodeConnections AWS AWS
## Capacité : rôle IAM
Lorsque vous créez une fonctionnalité, vous fournissez un rôle de fonctionnalité IAM qu'EKS utilise pour effectuer des actions en votre nom. Ce rôle doit :
+ Être dans le même AWS compte que le cluster et la ressource de capacité
+ Adopter une politique de confiance permettant au directeur du `capabilities.eks.amazonaws.com` service d'assumer le rôle
+ Disposez d'autorisations IAM adaptées au type de fonctionnalité et au cas d'utilisation, en fonction de vos besoins. Pour des informations détaillées sur les autorisations IAM requises, consultez [Connectez-vous aux référentiels Git avec AWS CodeConnections](integration-codeconnections.md)[Gérez les secrets des applications avec AWS Secrets Manager](integration-secrets-manager.md), et [Configurer les autorisations ACK](ack-permissions.md)
Il est recommandé de prendre en compte l'étendue des privilèges requis pour votre cas d'utilisation spécifique et d'accorder uniquement les autorisations nécessaires pour répondre à vos exigences. Par exemple, lorsque vous utilisez la fonctionnalité EKS pour Kube Resource Orchestrator, aucune autorisation IAM peut être requise, tandis que lorsque vous utilisez la fonctionnalité EKS pour les AWS contrôleurs pour Kubernetes, vous pouvez accorder un accès complet à un ou plusieurs services. AWS
**Important**
Bien que certains cas d'utilisation puissent justifier l'utilisation de privilèges administratifs étendus, suivez le principe du moindre privilège en n'accordant que les autorisations IAM minimales requises pour votre cas d'utilisation spécifique, en limitant l'accès à des ressources spécifiques à l'aide de clés ARNs et de conditions plutôt que d'utiliser des autorisations génériques.
Pour des informations détaillées sur la création et la configuration des rôles IAM liés aux fonctionnalités, consultez[Fonctionnalité Amazon EKS : rôle IAM](capability-role.md).
## Entrées d'accès EKS
Lorsque vous créez une fonctionnalité avec un rôle IAM, Amazon EKS crée automatiquement une entrée d'accès pour ce rôle sur votre cluster. Cette entrée d'accès accorde à la base de capacités Kubernetes les autorisations nécessaires pour fonctionner.
**Note**
Des entrées d'accès sont créées pour le cluster dans lequel la fonctionnalité est créée. Pour les déploiements d'Argo CD vers des clusters distants, vous devez créer des entrées d'accès sur ces clusters avec les autorisations appropriées pour que l'Argo CD puisse déployer et gérer des applications.
L'entrée d'accès inclut :
+ Le rôle IAM (ARN) en tant que principal
+ Politiques d'entrée d'accès spécifiques aux fonctionnalités qui accordent des autorisations Kubernetes de base
+ Étendue appropriée (à l'échelle du cluster ou étendue à l'espace de noms) en fonction du type de fonctionnalité
**Note**
Pour Argo CD, les autorisations étendues à l'espace de noms sont accordées à l'espace de noms spécifié dans la configuration des fonctionnalités (par défaut, c'est). `argocd`
**Politiques de saisie d'accès par défaut par fonctionnalité**
Chaque type de capacité accorde au rôle de capacité les autorisations requises, en définissant différentes politiques d'entrée d'accès par défaut comme suit :
**kro**
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSKROPolicy`(délimité par cluster)
Accorde les autorisations nécessaires pour surveiller, gérer ResourceGraphDefinitions et créer des instances de ressources personnalisées définies par RGDs.
**ACK**
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSACKPolicy`(délimité par cluster)
Accorde les autorisations nécessaires pour créer, lire, mettre à jour et supprimer des ressources personnalisées ACK dans tous les espaces de noms.
**Argo CD**
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDClusterPolicy`(délimité par cluster)
Accorde des autorisations au niveau du cluster pour qu'Argo CD découvre des ressources et gère les objets délimités au cluster.
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDPolicy`(limité à l'espace de noms)
Accorde des autorisations au niveau de l'espace de noms permettant à Argo CD de déployer et de gérer des applications. Limité à l'espace de noms spécifié dans la configuration des fonctionnalités (par défaut). `argocd`
Voir [Vérification des autorisations des stratégies d’accès](access-policy-permissions.md) pour des informations plus détaillées.
## Autorisations Kubernetes supplémentaires
Certaines fonctionnalités peuvent nécessiter des autorisations Kubernetes supplémentaires au-delà des politiques de saisie d'accès par défaut. Vous pouvez accorder ces autorisations en utilisant l'une des méthodes suivantes :
+ **Politiques de saisie d'accès** : associez des politiques gérées supplémentaires à l'entrée d'accès
+ **Kubernetes RBAC** : création `Role` de `ClusterRole` liaisons pour l'utilisateur Kubernetes de la fonctionnalité
**Autorisations du lecteur secret ACK**
Certains contrôleurs ACK doivent lire les secrets de Kubernetes pour récupérer des données sensibles telles que les mots de passe des bases de données. Les contrôleurs ACK suivants nécessitent un accès secret en lecture :
+ `acm`, `acmpca`, `documentdb`, `memorydb`, `mq`, `rds`, `secretsmanager`
Pour accorder des autorisations de lecture secrète, procédez comme suit :
1. Associer la politique d'`arn:aws:eks::aws:cluster-access-policy/AmazonEKSSecretReaderPolicy`accès à l'entrée d'accès de la fonctionnalité
1. Étendre la politique à des espaces de noms spécifiques où les ressources ACK référenceront des secrets ou accorderont un accès à l'échelle du cluster
**Important**
Les autorisations de lecture secrète sont limitées aux espaces de noms que vous spécifiez lors de l'association de la politique d'entrée d'accès. Cela vous permet de limiter les secrets auxquels la fonctionnalité peut accéder.
**autorisations de ressources arbitraires kro**
kro a besoin d'autorisations pour créer et gérer les ressources définies dans votre ResourceGraphDefinitions. Par défaut, Kro ne peut que se surveiller et RGDs se gérer lui-même.
Pour accorder à Kro l'autorisation de créer des ressources, procédez comme suit :
**Option 1 : accéder aux politiques d'entrée**
Associez des politiques d'entrée d'accès prédéfinies telles que `AmazonEKSAdminPolicy` ou `AmazonEKSEditPolicy` à l'entrée d'accès de la fonctionnalité.
**Option 2 : Kubernetes RBAC**
Créez un `ClusterRoleBinding` qui accorde à l'utilisateur Kubernetes de la fonctionnalité les autorisations nécessaires :
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: kro-cluster-admin
subjects:
- kind: User
name: arn:aws:sts::111122223333:assumed-role/my-kro-role/KRO
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
```
**Note**
Le nom d'utilisateur Kubernetes pour kro suit le modèle suivant : `arn:aws:sts::ACCOUNT_ID:assumed-role/ROLE_NAME/KRO`
Le nom de session `/KRO` (en majuscules) est automatiquement défini par la fonctionnalité EKS kro.
## Autorisations IAM requises par fonctionnalité
**kro (Kube Resource Orchestrator)**
Aucune autorisation IAM n'est requise. Vous pouvez créer un rôle de capacité sans politique attachée. Kro nécessite uniquement les autorisations RBAC de Kubernetes.
**ACK (AWS contrôleurs pour Kubernetes)**
Nécessite des autorisations pour gérer les AWS ressources qu'ACK créera et gérera. Vous devez définir les autorisations pour des services, des actions et des ressources spécifiques en fonction de vos besoins. Pour des informations détaillées sur la configuration des autorisations ACK, y compris les meilleures pratiques de production avec les sélecteurs de rôle IAM, consultez. [Configurer les autorisations ACK](ack-permissions.md)
**Argo CD**
Aucune autorisation IAM n'est requise par défaut. Des autorisations facultatives peuvent être nécessaires pour :
+ AWS Secrets Manager : si vous stockez les informations d'identification du référentiel Git dans Secrets Manager
+ AWS CodeConnections: en cas d'utilisation CodeConnections pour l'authentification du dépôt Git
+ Amazon ECR : si vous utilisez des diagrammes Helm stockés au format OCI dans Amazon ECR
## Bonnes pratiques de sécurité
### Le moindre privilège de l'IAM
Accordez à vos ressources de capacité uniquement les autorisations requises pour votre cas d'utilisation. Cela ne signifie pas que vous ne pouvez pas accorder des autorisations administratives étendues à vos fonctionnalités si nécessaire. Dans de tels cas, vous devez gérer l'accès à ces ressources de manière appropriée.
**Rôles liés aux capacités** :
+ **ACK** : Dans la mesure du possible, limitez les autorisations IAM aux AWS services et ressources spécifiques dont vos équipes ont besoin, en fonction des cas d'utilisation et des exigences
+ **Argo CD** : Restreindre l'accès à des référentiels Git et à des espaces de noms Kubernetes spécifiques
+ **kro** : nécessite un rôle de capacité pour la politique de confiance, mais aucune autorisation IAM n'est requise (utilise uniquement le cluster RBAC)
**Exemple** : au lieu de`"Resource": "*"`, spécifiez des modèles pour des ressources ou des groupes de ressources spécifiques.
```
"Resource": [
"arn:aws:s3:::my-app-*",
"arn:aws:rds:us-west-2:111122223333:db:prod-*"
]
```
Utilisez les clés de condition IAM pour restreindre davantage l'accès :
```
"Condition": {
"StringEquals": {
"aws:ResourceTag/Environment": "production"
}
}
```
Pour plus d'informations sur la configuration IAM, consultez la section des considérations relatives à chaque fonctionnalité.
### Isolation de l'espace de noms pour les secrets d'Argo CD
La fonctionnalité Argo CD gérée a accès à tous les secrets Kubernetes dans son espace de noms configuré (par défaut :). `argocd` Pour maintenir une posture de sécurité optimale, suivez les pratiques d'isolation des espaces de noms suivantes :
+ Conservez uniquement les secrets relatifs à Argo CD dans l'espace de noms Argo CD
+ Évitez de stocker des secrets d'application indépendants dans le même espace de noms qu'Argo CD
+ Utilisez des espaces de noms distincts pour les secrets d'application qui ne sont pas nécessaires pour les opérations sur Argo CD
Cette isolation garantit que l'accès secret d'Argo CD est limité aux seules informations d'identification dont il a besoin pour l'authentification du référentiel Git et pour d'autres opérations spécifiques à Argo CD.
### RBAC Kubernetes
Contrôlez quels utilisateurs et quels comptes de service peuvent créer et gérer des ressources de fonctionnalités. Il est recommandé de déployer des ressources de capacité dans des espaces de noms dédiés avec des politiques RBAC appropriées.
Exemple : rôle RBAC compatible avec ACK, permettant de gérer les ressources du compartiment S3 dans l'espace de `app-team` noms :
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: ack-s3-manager
namespace: app-team
rules:
- apiGroups: ["s3.services.k8s.aws"]
resources: ["buckets"]
verbs: ["get", "list", "create", "update", "delete"]
```
### Journaux d’audit
**CloudTrail**: Toutes les opérations de l'API EKS Capability (création, mise à jour, suppression) sont enregistrées AWS CloudTrail.
Activez la CloudTrail journalisation pour suivre :
+ Qui a créé ou modifié les fonctionnalités
+ Lorsque les configurations des capacités ont changé
+ Quels rôles de capacité sont utilisés
### Accès au réseau et points de terminaison VPC
#### Accès privé à l'API Argo CD
Vous pouvez restreindre l'accès au serveur d'API Argo CD en associant un ou plusieurs points de terminaison VPC au point de terminaison Argo CD hébergé. Cela permet une connectivité privée depuis votre VPC sans passer par l'Internet public. Le point de terminaison VPC fournit un accès à la fois à l'interface utilisateur Web d'Argo CD et à l'API Argo CD (y compris l'accès à la CLI).
**Note**
Points de terminaison VPC connectés aux points de terminaison de l'API Argo CD hébergés (à l'aide des fonctionnalités eks). *region*.amazonaws.com) ne prennent pas en charge les politiques relatives aux points de terminaison VPC.
#### Déploiement sur des clusters privés
La fonctionnalité Argo CD permet de déployer des applications sur des clusters EKS entièrement privés, offrant ainsi un avantage opérationnel significatif en éliminant le besoin de peering VPC ou de configurations réseau complexes. Cependant, lors de la conception de cette architecture, considérez qu'Argo CD extraira la configuration des référentiels Git (qui peuvent être publics) et l'appliquera à vos clusters privés.
Assurez-vous de :
+ Utiliser des référentiels Git privés pour les charges de travail sensibles
+ Mettre en œuvre des contrôles d'accès et une authentification appropriés au référentiel Git
+ Vérifiez et approuvez les modifications par le biais de pull requests avant de les fusionner
+ Envisagez d'utiliser les fenêtres de synchronisation d'Argo CD pour contrôler le moment où les déploiements peuvent avoir lieu
+ Surveillez les journaux d'audit d'Argo CD pour détecter les modifications de configuration non autorisées
### Conformité d’
Les fonctionnalités d'EKS sont entièrement gérées et possèdent les certifications de conformité d'Amazon EKS.
Pour obtenir des informations de conformité actuelles, consultez [la section AWS Services concernés par programme de conformité](https://aws.amazon.com/compliance/services-in-scope/).
## Étapes suivantes
+ [Configurer les autorisations ACK](ack-permissions.md)- Configurer les autorisations IAM pour ACK
+ [Configurer les autorisations Kro](kro-permissions.md)- Configurer Kubernetes RBAC pour kro
+ [Configurer les autorisations d'Argo CD](argocd-permissions.md)- Configurer l'intégration d'Identity Center pour Argo CD
+ [Dépannage des fonctionnalités EKS](capabilities-troubleshooting.md)- Résoudre les problèmes de sécurité et d'autorisation
# Gestion des identités et des accès pour Amazon EKS
AWS Identity and Access Management (IAM) est un AWS service qui permet à un administrateur de contrôler en toute sécurité l'accès aux ressources. AWS Des administrateurs IAM contrôlent les personnes qui peuvent être *authentifiées* (connectées) et *autorisées* (disposant d'autorisations) pour utiliser des ressources Amazon EKS. IAM est un AWS service que vous pouvez utiliser sans frais supplémentaires.
## Public ciblé
La façon dont vous utilisez AWS Identity and Access Management (IAM) varie en fonction du travail que vous effectuez dans Amazon EKS.
**Utilisateur du service** : si vous utilisez le service Amazon EKS pour accomplir votre tâche, votre administrateur vous fournit les informations d'identification et les autorisations dont vous avez besoin. Vous pourrez avoir besoin d'autorisations supplémentaires si vous utilisez davantage de fonctionnalités Amazon EKS. Si vous comprenez bien la gestion des accès, vous saurez demander les autorisations appropriées à votre administrateur. Si vous ne pouvez pas accéder à une fonctionnalité dans Amazon EKS, consultez [Dépannage IAM](security-iam-troubleshoot.md).
**Administrateur de service** : si vous êtes responsable des ressources Amazon EKS au sein de votre entreprise, vous disposez probablement d’un accès complet à Amazon EKS. Il vous incombe de déterminer les fonctionnalités et ressources Amazon EKS auxquelles les utilisateurs de votre service doivent avoir accès, c’est votre tâche. Vous devez ensuite soumettre les demandes à votre administrateur IAM pour modifier les autorisations des utilisateurs de votre service. Consultez les informations sur cette page pour comprendre les concepts de base d’IAM. Pour en savoir plus sur la façon dont votre entreprise peut utiliser IAM avec Amazon EKS, consultez [Fonctionnement d'Amazon EKS avec IAM](security-iam-service-with-iam.md).
**Administrateur IAM** : si vous êtes administrateur IAM, vous voudrez peut-être en savoir plus sur la manière de rédiger des politiques pour gérer l’accès à Amazon EKS. Pour afficher des exemples de politiques basées sur l'identité Amazon EKS que vous pouvez utiliser dans IAM, consultez [Exemples de politiques basées sur l'identité d'Amazon EKS](security-iam-id-based-policy-examples.md).
## Authentification par des identités
L'authentification est la façon dont vous vous connectez à AWS l'aide de vos informations d'identification. Vous devez être *authentifié* (connecté à AWS) en tant qu'utilisateur root du AWS compte, en tant qu'utilisateur IAM ou en assumant un rôle IAM.
Vous pouvez vous connecter en AWS tant qu'identité fédérée en utilisant les informations d'identification fournies par le biais d'une source d'identité. AWS Les utilisateurs de l'IAM Identity Center (IAM Identity Center), l'authentification unique de votre entreprise et vos informations d'identification Google ou Facebook sont des exemples d'identités fédérées. Lorsque vous vous connectez avec une identité fédérée, votre administrateur aura précédemment configuré une fédération d’identités avec des rôles IAM. Lorsque vous accédez à AWS l'aide de la fédération, vous assumez indirectement un rôle.
Selon le type d'utilisateur que vous êtes, vous pouvez vous connecter au portail AWS Management Console ou au portail AWS d'accès. Pour plus d'informations sur la connexion à AWS, consultez [Comment vous connecter à votre AWS compte dans](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) le *Guide de l'utilisateur de AWS connexion*.
Si vous y accédez AWS par programmation, AWS fournit un kit de développement logiciel (SDK) et une interface de ligne de commande (CLI) pour signer cryptographiquement vos demandes à l'aide de vos informations d'identification. Si vous n'utilisez pas d' AWS outils, vous devez signer vous-même les demandes. Pour plus d'informations sur l'utilisation de la méthode recommandée pour signer vous-même les demandes, consultez la section [Signature des demandes AWS d'API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html) dans le *guide de l'utilisateur IAM*.
Quelle que soit la méthode d’authentification que vous utilisez, vous devrez peut-être fournir des informations de sécurité supplémentaires. Par exemple, il vous AWS recommande d'utiliser l'authentification multifactorielle (MFA) pour renforcer la sécurité de votre compte. *Pour en savoir plus, consultez [Authentification multifactorielle](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html) dans le *guide de l'utilisateur d' AWS IAM Identity Center* et [Utilisation de l'authentification multifactorielle (MFA) AWS dans](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) le guide de l'utilisateur IAM.*
### AWS utilisateur root du compte
Lorsque vous créez un AWS compte, vous commencez par utiliser une seule identité de connexion qui donne un accès complet à tous les AWS services et ressources du compte. Cette identité est appelée *utilisateur root* du AWS compte et est accessible en vous connectant avec l'adresse e-mail et le mot de passe que vous avez utilisés pour créer le compte. Il est vivement recommandé de ne pas utiliser l’utilisateur racine pour vos tâches quotidiennes. Protégez vos informations d’identification d’utilisateur racine et utilisez-les pour effectuer les tâches que seul l’utilisateur racine peut effectuer. Pour obtenir la liste complète des tâches qui vous imposent de vous connecter en tant qu’utilisateur racine, consultez [Tâches nécessitant les informations d’identification de l’utilisateur racine](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) dans le *Guide de l’utilisateur IAM*.
### Utilisateurs et groupes IAM
Un [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) est une identité au sein de votre AWS compte qui possède des autorisations spécifiques pour une seule personne ou une seule application. Dans la mesure du possible, nous vous recommandons de vous appuyer sur des informations d’identification temporaires plutôt que de créer des utilisateurs IAM ayant des informations d’identification à long terme telles que des mots de passe et des clés d’accès. Toutefois, si certains cas d’utilisation spécifiques nécessitent des informations d’identification à long terme avec les utilisateurs IAM, nous vous recommandons d’effectuer une rotation des clés d’accès. Pour plus d’informations, consultez [Rotation régulière des clés d’accès pour les cas d’utilisation nécessitant des informations d’identification](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials) dans le *Guide de l’utilisateur IAM*.
Un [groupe IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) est une identité qui concerne un ensemble d’utilisateurs IAM. Vous ne pouvez pas vous connecter en tant que groupe. Vous pouvez utiliser les groupes pour spécifier des autorisations pour plusieurs utilisateurs à la fois. Les groupes permettent de gérer plus facilement les autorisations pour de grands ensembles d’utilisateurs. Par exemple, vous pouvez nommer un groupe *IAMAdmins*et lui donner les autorisations nécessaires pour administrer les ressources IAM.
Les utilisateurs sont différents des rôles. Un utilisateur est associé de manière unique à une personne ou une application, alors qu’un rôle est conçu pour être endossé par tout utilisateur qui en a besoin. Les utilisateurs disposent d’informations d’identification permanentes, mais les rôles fournissent des informations d’identification temporaires. Pour en savoir plus, consultez [Quand créer un utilisateur IAM (au lieu d’un rôle)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose) dans le *Guide de l’utilisateur IAM*.
### Rôles IAM
Un [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) est une identité au sein de votre AWS compte dotée d'autorisations spécifiques. Le concept ressemble à celui d’utilisateur IAM, mais le rôle IAM n’est pas associé à une personne en particulier. Vous pouvez assumer temporairement un rôle IAM dans le en AWS Management Console [changeant de rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html). Vous pouvez assumer un rôle en appelant une opération d' AWS API ou de AWS CLI ou en utilisant une URL personnalisée. Pour plus d’informations sur les méthodes d’utilisation des rôles, consultez [Utilisation de rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html) dans le *Guide de l’utilisateur IAM*.
Les rôles IAM avec des informations d’identification temporaires sont utiles dans les cas suivants :
+ **Accès utilisateur fédéré** : pour attribuer des autorisations à une identité fédérée, vous créez un rôle et définissez des autorisations pour le rôle. Quand une identité externe s’authentifie, l’identité est associée au rôle et reçoit les autorisations qui sont définies par celui-ci. Pour obtenir des informations sur les rôles pour la fédération, consultez [Création d’un rôle pour un fournisseur d’identité tiers (fédération)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html) dans le *Guide de l’utilisateur IAM*. Si vous utilisez IAM Identity Center, vous configurez un jeu d’autorisations. IAM Identity Center met en corrélation le jeu d’autorisations avec un rôle dans IAM afin de contrôler à quoi vos identités peuvent accéder après leur authentification. Pour plus d'informations sur les ensembles d'autorisations, consultez la section [Ensembles d'autorisations](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) dans le *guide de l'utilisateur d' AWS IAM Identity Center*.
+ **Autorisations d’utilisateur IAM temporaires** : un rôle ou un utilisateur IAM peut endosser un rôle IAM pour profiter temporairement d’autorisations différentes pour une tâche spécifique.
+ **Accès intercompte** : vous pouvez utiliser un rôle IAM pour permettre à un utilisateur (principal de confiance) d’un compte différent d’accéder aux ressources de votre compte. Les rôles constituent le principal moyen d’accorder l’accès intercompte. Cependant, avec certains AWS services, vous pouvez associer une politique directement à une ressource (au lieu d'utiliser un rôle comme proxy). Pour en savoir plus sur la différence entre les rôles et les politiques basées sur les ressources pour l’accès intercompte, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*.
+ **Accès interservices** — Certains AWS services utilisent des fonctionnalités d'autres AWS services. Par exemple, lorsque vous effectuez un appel dans un service, il est courant que ce service exécute des applications dans Amazon EC2 ou stocke des objets dans Amazon S3. Un service peut le faire en utilisant les autorisations d’appel du principal, une fonction du service ou un rôle lié au service.
+ **Sessions d'accès direct (FAS)** : lorsque vous utilisez un utilisateur ou un rôle IAM pour effectuer des actions AWS, vous êtes considéré comme un mandant. Lorsque vous utilisez certains services, vous pouvez effectuer une action qui initie une autre action dans un autre service. Le FAS utilise les autorisations du principal appelant un AWS service, associées au AWS service demandeur pour adresser des demandes aux services en aval. Les demandes FAS ne sont effectuées que lorsqu'un service reçoit une demande qui nécessite des interactions avec d'autres AWS services ou ressources pour être traitée. Dans ce cas, vous devez disposer d’autorisations nécessaires pour effectuer les deux actions. Pour plus de détails sur une politique lors de la formulation de demandes FAS, consultez [Transmission des sessions d’accès](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
+ **Rôle de service** : il s’agit d’un [rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) attribué à un service afin de réaliser des actions en votre nom. Un administrateur IAM peut créer, modifier et supprimer un rôle de service à partir d’IAM. Pour plus d'informations, consultez la section [Création d'un rôle pour déléguer des autorisations à un AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) dans le *Guide de l'utilisateur IAM*.
+ **Rôle lié à un service — Un rôle** lié à un service est un type de rôle lié à un service. AWS Le service peut endosser le rôle afin d’effectuer une action en votre nom. Les rôles liés au service apparaissent dans votre AWS compte et appartiennent au service. Un administrateur IAM peut consulter, mais ne peut pas modifier, les autorisations concernant les rôles liés à un service.
+ **Applications exécutées sur Amazon EC2** : vous pouvez utiliser un rôle IAM pour gérer les informations d'identification temporaires pour les applications qui s'exécutent sur une EC2 instance et qui envoient des requêtes AWS CLI ou AWS API. Cela est préférable au stockage des clés d'accès dans l' EC2 instance. Pour attribuer un AWS rôle à une EC2 instance et le rendre disponible pour toutes ses applications, vous devez créer un profil d'instance attaché à l'instance. Un profil d'instance contient le rôle et permet aux programmes exécutés sur l' EC2 instance d'obtenir des informations d'identification temporaires. Pour plus d'informations, consultez la section [Utilisation d'un rôle IAM pour accorder des autorisations aux applications exécutées sur des EC2 instances Amazon](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) dans le guide de l'*utilisateur IAM*.
Pour savoir dans quel cas utiliser des rôles ou des utilisateurs IAM, consultez [Quand créer un rôle IAM (au lieu d’un utilisateur)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role) dans le *Guide de l’utilisateur IAM*.
## Gestion des accès à l’aide de politiques
Vous contrôlez l'accès en AWS créant des politiques et en les associant à AWS des identités ou à des ressources. Une politique est un objet AWS qui, lorsqu'il est associé à une identité ou à une ressource, définit leurs autorisations. AWS évalue ces politiques lorsqu'un principal (utilisateur, utilisateur root ou session de rôle) fait une demande. Les autorisations dans les politiques déterminent si la demande est autorisée ou refusée. La plupart des politiques sont stockées AWS sous forme de documents JSON. Pour plus d’informations sur la structure et le contenu des documents de politique JSON, consultez [Vue d’ensemble des politiques JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) dans le *Guide de l’utilisateur IAM*.
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
Par défaut, les utilisateurs et les rôles ne disposent d’aucune autorisation. Pour octroyer aux utilisateurs des autorisations d’effectuer des actions sur les ressources dont ils ont besoin, un administrateur IAM peut créer des politiques IAM. L’administrateur peut ensuite ajouter les politiques IAM aux rôles et les utilisateurs peuvent assumer les rôles.
Les politiques IAM définissent les autorisations d’une action, quelle que soit la méthode que vous utilisez pour exécuter l’opération. Par exemple, supposons que vous disposiez d’une politique qui autorise l’action `iam:GetRole`. Un utilisateur appliquant cette politique peut obtenir des informations sur le AWS Management Console rôle à partir de la AWS CLI ou de l' AWS API.
### Politiques basées sur l’identité
Les politiques basées sur l’identité sont des documents de politique d’autorisations JSON que vous pouvez attacher à une identité telle qu’un utilisateur, un groupe d’utilisateurs ou un rôle IAM. Ces politiques contrôlent quel type d’actions des utilisateurs et des rôles peuvent exécuter, sur quelles ressources et dans quelles conditions. Pour découvrir comment créer une politique basée sur l’identité, 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*.
Les politiques basées sur l’identité peuvent être classées comme des *politiques en ligne* ou des *politiques gérées*. Les politiques en ligne sont intégrées directement à un utilisateur, groupe ou rôle. Les politiques gérées sont des politiques autonomes que vous pouvez associer à plusieurs utilisateurs, groupes et rôles dans votre AWS compte. Les politiques gérées incluent les politiques AWS gérées et les politiques gérées par le client. Pour découvrir comment choisir entre une politique gérée et une politique en ligne, consultez [Choix entre les politiques gérées et les politiques en ligne](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline) dans le *Guide de l’utilisateur IAM*.
### Politiques basées sur les ressources
Les politiques basées sur les ressources sont des documents de politique JSON que vous attachez à une ressource. Par exemple, les *politiques de confiance de rôle* IAM et les *politiques de compartiment* Amazon S3 sont des politiques basées sur les ressources. Dans les services qui sont compatibles avec les politiques basées sur les ressources, les administrateurs de service peuvent les utiliser pour contrôler l’accès à une ressource spécifique. Pour la ressource dans laquelle se trouve la politique, cette dernière définit quel type d’actions un principal spécifié peut effectuer sur cette ressource et dans quelles conditions. Vous devez [spécifier un principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) dans une politique basée sur les ressources. Les principaux peuvent inclure des comptes, des utilisateurs, des rôles, des utilisateurs fédérés ou AWS des services.
Les politiques basées sur les ressources sont des politiques en ligne situées dans ce service. Vous ne pouvez pas utiliser les politiques AWS gérées par IAM dans une stratégie basée sur les ressources.
### Listes de contrôle d'accès (ACLs)
Les listes de contrôle d'accès (ACLs) contrôlent les principaux (membres du compte, utilisateurs ou rôles) autorisés à accéder à une ressource. ACLs sont similaires aux politiques basées sur les ressources, bien qu'elles n'utilisent pas le format de document de politique JSON.
Amazon S3, AWS WAF et Amazon VPC sont des exemples de services compatibles. ACLs Pour en savoir plus ACLs, consultez la [présentation de la liste de contrôle d'accès (ACL)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) dans le *guide du développeur Amazon Simple Storage Service*.
### Autres types de politique
AWS prend en charge d'autres types de politiques moins courants. Ces types de politiques peuvent définir le nombre maximum d’autorisations qui vous sont accordées par des types de politiques plus courants.
+ **Limite d’autorisations** : une limite d’autorisations est une fonctionnalité avancée dans laquelle vous définissez le nombre maximal d’autorisations qu’une politique basée sur l’identité peut accorder à une entité IAM (utilisateur ou rôle IAM). Vous pouvez définir une limite d’autorisations pour une entité. Les autorisations qui en résultent sont l’intersection des politiques basées sur l’identité d’une entité et de ses limites d’autorisation. Les politiques basées sur les ressources qui spécifient l’utilisateur ou le rôle dans le champ `Principal` ne sont pas limitées par les limites d’autorisations. Un refus explicite dans l’une de ces politiques annule l’autorisation. Pour plus d’informations sur les limites d’autorisations, consultez [Limites d’autorisations pour des entités IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) dans le *Guide de l’utilisateur IAM*.
+ **Politiques de contrôle des services (SCPs)** : SCPs politiques JSON qui spécifient les autorisations maximales pour une organisation ou une unité organisationnelle (UO) dans AWS Organizations. AWS Organizations est un service permettant de regrouper et de gérer de manière centralisée plusieurs AWS comptes détenus par votre entreprise. Si vous activez toutes les fonctionnalités d'une organisation, vous pouvez appliquer des politiques de contrôle des services (SCPs) à l'un ou à l'ensemble de vos comptes. Le SCP limite les autorisations pour les entités des comptes membres, y compris pour chaque utilisateur root AWS du compte. Pour plus d'informations sur les Organizations et consultez SCPs les [politiques de contrôle des services](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) dans le *Guide de l'utilisateur AWS des Organizations*.
+ **Politiques de session** : les politiques de session sont des politiques avancées que vous utilisez en tant que paramètre lorsque vous créez par programmation une session temporaire pour un rôle ou un utilisateur fédéré. Les autorisations de la session obtenue sont une combinaison des politiques basées sur l’identité de l’utilisateur ou du rôle et des politiques de session. Les autorisations peuvent également provenir d’une politique basée sur les ressources. Un refus explicite dans l’une de ces politiques annule l’autorisation. Pour plus d’informations, consultez [Politiques de session](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) dans le *Guide de l’utilisateur IAM*.
### Plusieurs types de politique
Lorsque plusieurs types de politiques s’appliquent à la requête, les autorisations en résultant sont plus compliquées à comprendre. Pour savoir comment AWS déterminer s'il faut autoriser une demande lorsque plusieurs types de politiques sont impliqués, consultez la section [Logique d'évaluation des politiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) dans le *guide de l'utilisateur IAM*.
# Fonctionnement d'Amazon EKS avec IAM
Avant d'utiliser IAM pour gérer l'accès à Amazon EKS, vous devez comprendre quelles sont les fonctionnalités IAM qui peuvent être utilisées dans cette situation. Pour obtenir une vue d'ensemble de la manière dont Amazon EKS et les autres AWS services fonctionnent avec IAM, consultez la section [AWS Services compatibles avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dans le guide de l'utilisateur d'*IAM*.
**Topics**
+ [Politiques basées sur l'identité Amazon EKS](#security-iam-service-with-iam-id-based-policies)
+ [Politiques basées sur les ressources Amazon EKS](#security-iam-service-with-iam-resource-based-policies)
+ [Autorisation basée sur des identifications Amazon EKS](#security-iam-service-with-iam-tags)
+ [Rôles IAM Amazon EKS](#security-iam-service-with-iam-roles)
## Politiques basées sur l'identité Amazon EKS
Avec les politiques IAM basées sur l'identité, vous pouvez spécifier des actions et ressources autorisées ou refusées, ainsi que les conditions dans lesquelles les actions sont autorisées ou refusées. Amazon EKS est compatible avec des actions, des ressources et des clés de condition spécifiques. Pour en savoir plus sur tous les éléments que vous utilisez dans une politique JSON, consultez [Références des éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) dans le *Guide de l'utilisateur IAM*.
### Actions
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément `Action` d’une politique JSON décrit les actions que vous pouvez utiliser pour autoriser ou refuser l’accès à une politique. Les actions de stratégie portent généralement le même nom que l'opération AWS d'API associée. Il existe certaines exceptions, telles que les *actions d’autorisation uniquement* qui ne correspondent à aucune opération API. Certaines opérations nécessitent également plusieurs actions dans une politique. Ces actions supplémentaires sont nommées *actions dépendantes*.
Intégration d'actions dans une politique afin d'accorder l'autorisation d'exécuter les opérations associées.
Les actions de politique dans Amazon EKS utilisent le préfixe suivant avant l'action : `eks:`. Par exemple, pour accorder à une personne l'autorisation d'obtenir des informations descriptives sur un cluster Amazon EKS, incluez l'action `DescribeCluster` dans sa politique. Les déclarations de politique doivent inclure un élément `Action` ou `NotAction`.
Pour spécifier plusieurs actions dans une seule déclaration, séparez-les par des virgules comme suit :
```
"Action": ["eks:action1", "eks:action2"]
```
Vous pouvez aussi spécifier plusieurs actions à l’aide de caractères génériques (\$1). Par exemple, pour spécifier toutes les actions qui commencent par le mot `Describe`, incluez l’action suivante :
```
"Action": "eks:Describe*"
```
Pour afficher la liste des actions Amazon EKS, 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) de la *Référence de l'autorisation de service*.
### Ressources
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément de politique JSON `Resource` indique le ou les objets auxquels l’action s’applique. Les instructions doivent inclure un élément `Resource` ou `NotResource`. Il est recommandé de définir une ressource à l’aide de son [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Vous pouvez le faire pour des actions qui prennent en charge un type de ressource spécifique, connu sous la dénomination *autorisations de niveau ressource*.
Pour les actions qui ne prennent pas en charge les autorisations au niveau des ressources, telles que les opérations de listage, utilisez un caractère générique (\$1) pour indiquer que la déclaration s’applique à toutes les ressources.
```
"Resource": "*"
```
La ressource de cluster Amazon EKS intègre l'ARN suivant.
```
arn:aws: eks:region-code:account-id:cluster/cluster-name
```
Pour plus d'informations sur le format de ARNs, consultez [Amazon resource names (ARNs) et espaces de noms AWS de services](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) Amazon.
Par exemple, pour spécifier le cluster dont le nom figure *my-cluster* dans votre instruction, utilisez l'ARN suivant :
```
"Resource": "arn:aws: eks:region-code:111122223333:cluster/my-cluster"
```
Pour spécifier tous les clusters appartenant à un compte et à une AWS région spécifiques, utilisez le caractère générique (\$1) :
```
"Resource": "arn:aws: eks:region-code:111122223333:cluster/*"
```
Certaines actions Amazon EKS, telles que celles permettant de créer des ressources, ne peuvent pas être effectuées sur une ressource spécifique. Dans ces cas-là, vous devez utiliser le caractère générique (\$1).
```
"Resource": "*"
```
*Pour consulter la liste des types de ressources Amazon EKS et leurs caractéristiques ARNs, consultez la section [Ressources définies par Amazon Elastic Kubernetes](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-resources-for-iam-policies) Service dans le Service Authorization Reference.* Pour connaître les actions avec lesquelles vous pouvez spécifier l'ARN de chaque ressource, 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).
### Clés de condition
Amazon EKS définit son propre ensemble de clés de condition et est également compatible avec l'utilisation de certaines clés de condition globales. Pour voir toutes les clés de condition AWS globales, consultez la section [Clés contextuelles de condition AWS globale](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le *guide de l'utilisateur IAM*.
Vous pouvez définir des clés de condition lors de l'association d'un fournisseur OpenID Connect à votre cluster. Pour de plus amples informations, veuillez consulter [Exemple de politique IAM](authenticate-oidc-identity-provider.md#oidc-identity-provider-iam-policy).
Toutes les actions Amazon EC2 prennent en charge les clés de condition `aws:RequestedRegion` et `ec2:Region`. Pour plus d'informations, voir [Exemple : restriction de l'accès à une AWS région spécifique](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region).
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).
### Exemples
Pour voir des exemples de politiques Amazon EKS basées sur l'identité, consultez [Exemples de politiques basées sur l'identité d'Amazon EKS](security-iam-id-based-policy-examples.md).
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`.
Pour plus d'informations sur l'utilisation du ConfigMap, consultez[Accorder aux utilisateurs et aux rôles IAM l'accès à Kubernetes APIs](grant-k8s-access.md).
## Politiques basées sur les ressources Amazon EKS
Amazon EKS ne prend pas en charge les politiques basées sur les ressources.
## Autorisation basée sur des identifications Amazon EKS
Vous pouvez attacher des identifications aux ressources Amazon EKS ou transmettre des identifications dans une demande à Amazon EKS. Pour contrôler l'accès basé sur des identifications, vous devez fournir les informations d'identifications dans l'[élément de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) d'une politique utilisant les clés de condition `aws:ResourceTag/key-name `, `aws:RequestTag/key-name ` ou `aws:TagKeys`. Pour plus d'informations sur l'étiquetage des ressources Amazon EKS, consultez [Organiser les ressources Amazon EKS à l’aide de balises](eks-using-tags.md). Pour plus d'informations sur les actions dans lesquelles vous pouvez utiliser des balises avec des clés de condition, consultez [Actions définies par Amazon EKS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) dans [Référence de l'autorisation de service](https://docs.aws.amazon.com/service-authorization/latest/reference/reference.html).
## Rôles IAM Amazon EKS
Un [rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) est une entité de votre AWS compte qui possède des autorisations spécifiques.
### Utilisation d'informations d'identification temporaires avec Amazon EKS
Vous pouvez utiliser des informations d’identification temporaires pour vous connecter à l’aide de la fédération, endosser un rôle IAM ou encore pour endosser un rôle intercompte. Vous obtenez des informations d'identification de sécurité temporaires en appelant AWS des opérations d'API STS telles que [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)ou [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html).
Amazon EKS est compatible avec l'utilisation des informations d'identification temporaires.
### Rôles liés à un service
Les [rôles liés aux](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) AWS services permettent aux services d'accéder aux ressources d'autres services pour effectuer une action en votre nom. Les rôles liés à un service s’affichent dans votre compte IAM et sont la propriété du service. Un administrateur peut afficher les autorisations des rôles liés à un service, mais ne peut pas les modifier.
Amazon EKS prend en charge les rôles liés à un service. Pour plus d'informations sur la création ou la gestion des rôles liés à un service Amazon EKS, consultez [Utilisation des rôles liés à un service pour Amazon EKS](using-service-linked-roles.md).
### Rôles du service
Cette fonction permet à un service d’endosser une [fonction du service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-role) en votre nom. Ce rôle autorise le service à accéder à des ressources d’autres services pour effectuer une action en votre nom. Les rôles de service s’affichent dans votre compte IAM et sont la propriété du compte. Cela signifie qu’un administrateur IAM peut modifier les autorisations associées à ce rôle. Toutefois, une telle action peut perturber le bon fonctionnement du service.
Amazon EKS prend en charge les rôles de service. Pour plus d’informations, consultez [Rôle IAM de cluster Amazon EKS](cluster-iam-role.md) et [Rôle IAM de nœud Amazon EKS](create-node-role.md).
### Choix d'un rôle IAM dans Amazon EKS
Lorsque vous créez une ressource de cluster dans Amazon EKS, vous devez choisir un rôle pour permettre à Amazon EKS d'accéder à plusieurs autres AWS ressources en votre nom. Si vous avez déjà créé un rôle de service, Amazon EKS vous propose une liste de rôles parmi lesquels choisir. Il est important de choisir un rôle auquel les politiques gérées par Amazon EKS sont attachées. Pour plus d'informations, consultez [Recherche d'un rôle de cluster existant](cluster-iam-role.md#check-service-role) et [Recherche d'un rôle de nœud existant](create-node-role.md#check-worker-node-role).
# Exemples de politiques basées sur l'identité d'Amazon EKS
Par défaut, les utilisateurs et les rôles IAM n’ont pas l’autorisation de créer ou de modifier des ressources Amazon EKS. Ils ne peuvent pas non plus effectuer de tâches à l'aide de la AWS Management Console AWS CLI ou de AWS l'API. Un administrateur IAM doit créer des politiques IAM autorisant les utilisateurs et les rôles à exécuter des opérations d'API spécifiques sur les ressources spécifiées dont ils ont besoin. Il doit ensuite attacher ces politiques aux utilisateurs ou aux groupes IAM ayant besoin de ces autorisations.
Pour apprendre à créer une politique basée sur l'identité IAM à l'aide de ces exemples de documents de politique JSON, veuillez consulter [Création de politiques dans l'onglet JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) dans le *Guide de l'utilisateur IAM*.
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`.
Pour plus d'informations sur l'utilisation du ConfigMap, consultez[Accorder aux utilisateurs et aux rôles IAM l'accès à Kubernetes APIs](grant-k8s-access.md).
**Topics**
+ [Bonnes pratiques en matière de politiques](#security-iam-service-with-iam-policy-best-practices)
+ [Utilisation de la console Amazon EKS](#security-iam-id-based-policy-examples-console)
+ [Autorisation des utilisateurs IAM à afficher leurs propres autorisations](#security-iam-id-based-policy-examples-view-own-permissions)
+ [Création d'un cluster Kubernetes sur le cloud AWS](#policy-create-cluster)
+ [Créer un cluster Kubernetes local sur un Outpost](#policy-create-local-cluster)
+ [Mise à jour d'un cluster Kubernetes](#policy-example1)
+ [Affichage de la liste ou description de tous les clusters](#policy-example2)
## Bonnes pratiques en matière de politiques
Les politiques basées sur l'identité déterminent si une personne peut créer, consulter ou supprimer des ressources Amazon EKS dans votre compte. Ces actions peuvent entraîner des frais pour votre AWS compte. Lorsque vous créez ou modifiez des politiques basées sur l’identité, suivez ces instructions et recommandations :
+ **Commencez AWS par les politiques gérées et passez aux autorisations du moindre privilège : pour commencer à accorder des autorisations** à vos utilisateurs et à vos charges de travail, utilisez les *politiques AWS gérées* qui accordent des autorisations pour de nombreux cas d'utilisation courants. Ils sont disponibles dans votre AWS compte. Nous vous recommandons de réduire davantage les autorisations en définissant des politiques gérées par les AWS clients spécifiques à vos cas d'utilisation. Pour plus d’informations, consultez [politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [politiques gérées par AWS pour les activités professionnelles](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) dans le *Guide de l’utilisateur IAM*.
+ **Accordez les autorisations de moindre privilège** : lorsque vous définissez des autorisations avec des politiques IAM, accordez uniquement les autorisations nécessaires à l’exécution d’une seule tâche. Pour ce faire, vous définissez les actions qui peuvent être entreprises sur des ressources spécifiques dans des conditions spécifiques, également appelées *autorisations de moindre privilège*. Pour plus d’informations sur l’utilisation d’IAM pour appliquer des autorisations, consultez [politiques et autorisations dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez des conditions dans les politiques IAM pour restreindre davantage l’accès** : vous pouvez ajouter une condition à vos politiques afin de limiter l’accès aux actions et aux ressources. Par exemple, vous pouvez écrire une condition de politique pour spécifier que toutes les demandes doivent être envoyées via SSL. Vous pouvez également utiliser des conditions pour accorder l'accès aux actions de service si elles sont utilisées par le biais d'un AWS service spécifique, tel que AWS CloudFormation. Pour plus d’informations, consultez [Conditions pour éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez l’Analyseur d’accès IAM pour valider vos politiques IAM afin de garantir des autorisations sécurisées et fonctionnelles** : l’Analyseur d’accès IAM valide les politiques nouvelles et existantes de manière à ce que les politiques IAM respectent le langage de politique IAM (JSON) et les bonnes pratiques IAM. IAM Access Analyzer fournit plus de 100 vérifications de politiques et des recommandations exploitables pour vous aider à créer des politiques sécurisées et fonctionnelles. Pour plus d’informations, consultez [Validation de politique IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) dans le *Guide de l’utilisateur IAM*.
+ **Exiger l'authentification multifactorielle (MFA**) : si vous avez un scénario qui nécessite des utilisateurs IAM ou un utilisateur root dans AWS votre compte, activez l'authentification MFA pour une sécurité accrue. Pour exiger le MFA lorsque des opérations d'API sont appelées, ajoutez des conditions MFA à vos politiques. Pour plus d’informations, consultez [Configuration de l’accès aux API protégé par MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) dans le *Guide de l’utilisateur IAM*.
Pour plus d’informations sur les bonnes pratiques dans IAM, consultez [Bonnes pratiques de sécurité dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) dans le *Guide de l’utilisateur IAM*.
## Utilisation de la console Amazon EKS
Pour accéder à la console Amazon EKS, un [principal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) doit disposer d'un ensemble minimum d'autorisations. Ces autorisations permettent au principal de répertorier et de consulter les informations relatives aux ressources Amazon EKS de votre AWS compte. Si vous créez une politique basée sur l’identité qui est plus restrictive que les autorisations minimales requises, la console ne fonctionnera pas comme prévu pour les principaux auxquels cette politique est associée.
Pour garantir que vos principaux IAM puissent toujours utiliser la console Amazon EKS, créez une politique avec votre propre nom unique, par exemple `AmazonEKSAdminPolicy`. Attachez la politique aux principaux. Pour plus d'informations, consultez la rubrique [Ajout et suppression d'autorisations basées sur l'identité IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) du *Guide de l'utilisateur IAM*.
**Important**
L'exemple de politique suivant permet à un principal d'afficher des informations dans l'onglet **Configuration** sur la console. Pour afficher les informations dans les onglets **Vue d'ensemble** et **Ressources** du AWS Management Console, le principal doit également disposer des autorisations Kubernetes. Pour de plus amples informations, veuillez consulter [Autorisations requises](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "eks.amazonaws.com"
}
}
}
]
}
```
Il n'est pas nécessaire d'accorder des autorisations de console minimales aux principaux qui appellent uniquement la AWS CLI ou l' AWS API. Autorisez plutôt l’accès uniquement aux actions qui correspondent à l’opération API que vous essayez d’effectuer.
## Autorisation des utilisateurs IAM à afficher leurs propres autorisations
Cet exemple montre comment créer une politique qui permet aux utilisateurs IAM d’afficher les politiques en ligne et gérées attachées à leur identité d’utilisateur. Cette politique inclut les autorisations permettant d'effectuer cette action sur la console ou par programmation à l'aide de la AWS CLI ou AWS de l'API.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
## Création d'un cluster Kubernetes sur le cloud AWS
Cet exemple de politique inclut les autorisations minimales requises pour créer un cluster Amazon EKS nommé *my-cluster* dans la *us-west-2* AWS région. Vous pouvez remplacer la AWS région par la AWS région dans laquelle vous souhaitez créer un cluster. Si vous voyez un avertissement indiquant que **les actions de votre politique ne prennent pas en charge les autorisations au niveau des ressources et nécessitent que vous choisissiez `All resources` de le faire** AWS Management Console, il peut être ignoré en toute sécurité. Si votre compte possède déjà le rôle *AWSServiceRoleForAmazonEKS*, vous pouvez supprimer l'action `iam:CreateServiceLinkedRole` de la politique. Si vous avez déjà créé un cluster Amazon EKS dans votre compte, ce rôle existe déjà, sauf si vous l’avez supprimé.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "eks:CreateCluster",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::111122223333:role/aws-service-role/eks.amazonaws.com/AWSServiceRoleForAmazonEKS",
"Condition": {
"ForAnyValue:StringEquals": {
"iam:AWSServiceName": "eks"
}
}
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/cluster-role-name"
}
]
}
```
## Créer un cluster Kubernetes local sur un Outpost
Cet exemple de politique inclut les autorisations minimales requises pour créer un cluster local Amazon EKS nommé *my-cluster* sur un avant-poste de la *us-west-2* AWS région. Vous pouvez remplacer la AWS région par la AWS région dans laquelle vous souhaitez créer un cluster. Si vous voyez un avertissement indiquant que **les actions de votre politique ne prennent pas en charge les autorisations au niveau des ressources et nécessitent que vous choisissiez `All resources` de le faire** AWS Management Console, il peut être ignoré en toute sécurité. Si votre compte possède déjà le rôle `AWSServiceRoleForAmazonEKSLocalOutpost`, vous pouvez supprimer l'action `iam:CreateServiceLinkedRole` de la politique. Si vous avez déjà créé un cluster Amazon EKS local sur un Outpost dans votre compte, ce rôle existe déjà, sauf si vous l’avez supprimé.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "eks:CreateCluster",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster"
},
{
"Action": [
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"iam:GetRole"
],
"Resource": "*",
"Effect": "Allow"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::111122223333:role/aws-service-role/outposts.eks-local.amazonaws.com/AWSServiceRoleForAmazonEKSLocalOutpost"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole",
"iam:ListAttachedRolePolicies"
],
"Resource": "arn:aws:iam::111122223333:role/cluster-role-name"
},
{
"Action": [
"iam:CreateInstanceProfile",
"iam:TagInstanceProfile",
"iam:AddRoleToInstanceProfile",
"iam:GetInstanceProfile",
"iam:DeleteInstanceProfile",
"iam:RemoveRoleFromInstanceProfile"
],
"Resource": "arn:aws:iam::*:instance-profile/eks-local-*",
"Effect": "Allow"
}
]
}
```
## Mise à jour d'un cluster Kubernetes
Cet exemple de politique inclut l'autorisation minimale requise pour mettre à jour un cluster nommé *my-cluster* dans la région us-west-2. AWS
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "eks:UpdateClusterVersion",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster"
}
]
}
```
## Affichage de la liste ou description de tous les clusters
Cet exemple de politique inclut les autorisations minimales requises pour répertorier et décrire tous les clusters de votre compte. Un [principal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) doit être capable de répertorier et de décrire les clusters pour utiliser la commande `update-kubeconfig` AWS CLI.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:DescribeCluster",
"eks:ListClusters"
],
"Resource": "*"
}
]
}
```
# Utilisation des rôles liés à un service pour Amazon EKS
Amazon Elastic Kubernetes Service utilise les [rôles liés au service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) Gestion des identités et des accès AWS (IAM). Un rôle lié à un service est un type unique de rôle IAM lié directement à Amazon EKS. Les rôles liés à un service sont prédéfinis par Amazon EKS et incluent toutes les autorisations requises par le service pour appeler d'autres services AWS en votre nom.
**Topics**
+ [Utilisation de rôles pour les clusters Amazon EKS](using-service-linked-roles-eks.md)
+ [Utilisation de rôles pour les groupes de nœuds Amazon EKS](using-service-linked-roles-eks-nodegroups.md)
+ [Utilisation de rôles pour les profils Amazon EKS Fargate](using-service-linked-roles-eks-fargate.md)
+ [Utilisation de rôles pour connecter un cluster Kubernetes à Amazon EKS](using-service-linked-roles-eks-connector.md)
+ [Utilisation de rôles pour les clusters locaux Amazon EKS sur Outpost](using-service-linked-roles-eks-outpost.md)
+ [Utilisation des rôles pour le tableau de bord Amazon EKS](using-service-linked-roles-eks-dashboard.md)
# Utilisation de rôles pour les clusters Amazon EKS
Amazon Elastic Kubernetes Service utilise les [rôles liés au service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) Gestion des identités et des accès AWS (IAM). Un rôle lié à un service est un type unique de rôle IAM lié directement à Amazon EKS. Les rôles liés à un service sont prédéfinis par Amazon EKS et incluent toutes les autorisations requises par le service pour appeler d'autres services AWS en votre nom.
Un rôle lié à un service facilite la configuration d’Amazon EKS, car vous n’avez pas à ajouter manuellement les autorisations nécessaires. Amazon EKS définit les autorisations de ses rôles liés à un service ; sauf définition contraire, seul Amazon EKS peut endosser ses rôles. Les autorisations définies comprennent la politique d'approbation et la politique d'autorisation. De plus, cette politique d'autorisation ne peut pas être attachée à une autre entité IAM.
Vous pouvez supprimer un rôle lié à un service uniquement après la suppression préalable de ses ressources connexes. Vos ressources Amazon EKS sont ainsi protégées, car vous ne pouvez pas involontairement supprimer l’autorisation d’accéder aux ressources.
Pour plus d'informations sur les autres services prenant en charge les rôles liés à un service, consultez les services [AWS opérationnels avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) et recherchez les services présentant la mention **Yes** (Oui) dans la colonne **Service-linked roles** (Rôles liés à un service). Choisissez un **Yes (oui)** ayant un lien permettant de consulter les détails du rôle pour ce service.
## Autorisations du rôle lié à un service pour Amazon EKS
Amazon EKS utilise le rôle lié à un service nommé `AWSServiceRoleForAmazonEKS`. Ce rôle permet à Amazon EKS de gérer les clusters de votre compte. Les politiques attachées permettent au rôle de gérer les ressources suivantes : interfaces réseau, groupes de sécurité, journaux et VPC.
**Note**
Le rôle lié à un service `AWSServiceRoleForAmazonEKS` est distinct du rôle requis pour la création de cluster. Pour de plus amples informations, consultez [Rôle IAM de cluster Amazon EKS](cluster-iam-role.md).
Le rôle lié à un service `AWSServiceRoleForAmazonEKS` approuve les services suivants pour endosser le rôle :
+ `eks.amazonaws.com`
La politique d'autorisations liée au rôle permet à Amazon EKS de réaliser les actions suivantes sur les ressources spécifiées :
+ [AmazonEKSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html)
Vous devez configurer les autorisations de manière à permettre à une entité IAM (comme un utilisateur, un groupe ou un rôle) de créer, modifier ou supprimer un rôle lié à un service. Pour plus d'informations, consultez [Autorisations de rôles liés à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dans le *Guide de l'utilisateur IAM*.
## Création d'un rôle lié à un service pour Amazon EKS
Vous n’avez pas besoin de créer manuellement un rôle lié à un service. Lorsque vous créez un cluster dans la AWS Management Console, AWS CLI ou l’AWS API, Amazon EKS crée le rôle lié à un service pour vous.
Si vous supprimez ce rôle lié à un service et que vous avez ensuite besoin de le recréer, vous pouvez utiliser la même procédure pour recréer le rôle dans votre compte. Lorsque vous créez un cluster, Amazon EKS crée automatiquement le rôle lié au service à nouveau.
## Modification d'un rôle lié à un service pour Amazon EKS
Amazon EKS ne vous autorise pas à modifier le rôle lié à un service `AWSServiceRoleForAmazonEKS`. Une fois que vous avez créé un rôle lié à un service, vous ne pouvez pas changer le nom du rôle, car plusieurs entités peuvent faire référence à ce rôle. Néanmoins, vous pouvez modifier la description du rôle à l’aide d’IAM. Pour plus d’informations, consultez [Modification d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) dans le *IAM Guide de l’utilisateur*.
## Suppression d'un rôle lié à un service pour Amazon EKS
Si vous n’avez plus besoin d’utiliser une fonctionnalité ou un service qui nécessite un rôle lié à un service, nous vous recommandons de supprimer ce rôle. De cette façon, vous n'avez aucune entité inutilisée qui n'est pas surveillée ou gérée activement. Cependant, vous devez nettoyer votre rôle lié à un service avant de pouvoir le supprimer manuellement.
### Nettoyer un rôle lié à un service
Avant de pouvoir utiliser IAM pour supprimer un rôle lié à un service, vous devez supprimer toutes les ressources utilisées par le rôle.
**Note**
Si le service Amazon EKS utilise le rôle lorsque vous essayez de supprimer les ressources, la suppression peut échouer. Si cela se produit, patientez quelques minutes et réessayez.
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dans le volet de navigation de gauche, choisissez **Clusters**.
1. Si votre cluster possède des groupes de nœuds ou des profils Fargate, vous devez les supprimer avant de pouvoir supprimer le cluster. Pour plus d’informations, consultez [Supprimer un groupe de nœuds gérés de votre cluster](delete-managed-node-group.md) et [Supprimer un profil Fargate](delete-fargate-profile.md).
1. Dans la page **Clusters**, choisissez le cluster à supprimer et cliquez sur **Delete** (Supprimer).
1. Tapez le nom du cluster dans la fenêtre de confirmation de suppression, puis choisissez **Delete** (Supprimer).
1. Répétez cette procédure pour tous les autres clusters de votre compte. Attendez la fin de toutes les opérations de suppression.
### Suppression manuelle du rôle lié au service
Utilisez la console IAM, l'interface de ligne de commande AWS ou l'API AWS pour supprimer le rôle lié à un service `AWSServiceRoleForAmazonEKS`. Pour plus d'informations, consultez [Suppression d'un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) dans le *Guide de l'utilisateur IAM*.
## Régions prises en charge pour les rôles liés à un service Amazon EKS
Amazon EKS prend en charge l'utilisation des rôles liés à un service dans toutes les régions où le service est disponible. Pour plus d'informations, consultez [Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html) (langue française non garantie).
# Utilisation de rôles pour les groupes de nœuds Amazon EKS
Amazon EKS utilise les [rôles liés au service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) de la gestion des identités et des accès AWS (IAM). Un rôle lié à un service est un type unique de rôle IAM lié directement à Amazon EKS. Les rôles liés à un service sont prédéfinis par Amazon EKS et incluent toutes les autorisations requises par le service pour appeler d'autres services AWS en votre nom.
Un rôle lié à un service facilite la configuration d’Amazon EKS, car vous n’avez pas à ajouter manuellement les autorisations nécessaires. Amazon EKS définit les autorisations de ses rôles liés à un service ; sauf définition contraire, seul Amazon EKS peut endosser ses rôles. Les autorisations définies comprennent la politique d'approbation et la politique d'autorisation. De plus, cette politique d'autorisation ne peut pas être attachée à une autre entité IAM.
Vous pouvez supprimer un rôle lié à un service uniquement après la suppression préalable de ses ressources connexes. Vos ressources Amazon EKS sont ainsi protégées, car vous ne pouvez pas involontairement supprimer l’autorisation d’accéder aux ressources.
Pour plus d'informations sur les autres services prenant en charge les rôles liés à un service, consultez les services [AWS opérationnels avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) et recherchez les services présentant la mention **Yes** (Oui) dans la colonne **Service-linked roles** (Rôles liés à un service). Choisissez un **Yes (oui)** ayant un lien permettant de consulter les détails du rôle pour ce service.
## Autorisations du rôle lié à un service pour Amazon EKS
Amazon EKS utilise le rôle lié à un service nommé `AWSServiceRoleForAmazonEKSNodegroup`. Ce rôle permet à Amazon EKS de gérer les groupes de nœuds de votre compte. La politique `AWSServiceRoleForAmazonEKSNodegroup` attachée permet au rôle de gérer les ressources suivantes : groupes Auto Scaling, groupes de sécurité, modèles de lancement et profils d’instance IAM. Pour de plus amples informations, consultez [AWS politique gérée : AWSService RoleForAmazon EKSNodegroup](security-iam-awsmanpol.md#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup).
Le rôle lié à un service `AWSServiceRoleForAmazonEKSNodegroup` approuve les services suivants pour endosser le rôle :
+ `eks-nodegroup.amazonaws.com`
La politique d'autorisations liée au rôle permet à Amazon EKS de réaliser les actions suivantes sur les ressources spécifiées :
+ [AWSServiceRoleForAmazonEKSNodegroup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRoleForAmazonEKSNodegroup.html)
Vous devez configurer les autorisations de manière à permettre à une entité IAM (comme un utilisateur, un groupe ou un rôle) de créer, modifier ou supprimer un rôle lié à un service. Pour plus d'informations, consultez [Autorisations de rôles liés à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dans le *Guide de l'utilisateur IAM*.
## Création d'un rôle lié à un service pour Amazon EKS
Vous n’avez pas besoin de créer manuellement un rôle lié à un service. Lorsque vous créez un groupe de nœuds dans la AWS Management Console, l’AWS CLI ou l’API AWS, Amazon EKS crée le rôle lié à un service pour vous.
**Important**
Ce rôle lié à un service peut apparaître dans votre compte si vous avez effectué une action dans un autre service qui utilise les fonctions prises en charge par ce rôle. Si vous utilisiez le service Amazon EKS avant le 1er janvier 2017, date à laquelle il a commencé à prendre en charge les rôles liés à un service, Amazon EKS a créé le rôle AWSServiceRoleForAmazonEKSNodegroup dans votre compte. Pour en savoir plus, consultez [Un nouveau rôle est apparu dans mon compte IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).
### Création d'un rôle lié à un service dans Amazon EKS (API AWS)
Vous n’avez pas besoin de créer manuellement un rôle lié à un service. Lorsque vous créez un groupe de nœuds géré dans la AWS Management Console, l’AWS CLI ou l’API AWS, Amazon EKS crée le rôle lié à un service pour vous.
Si vous supprimez ce rôle lié à un service et que vous avez ensuite besoin de le recréer, vous pouvez utiliser la même procédure pour recréer le rôle dans votre compte. Lorsque vous créez un autre groupe de nœuds gérés, Amazon EKS crée automatiquement le rôle lié au service.
## Modification d'un rôle lié à un service pour Amazon EKS
Amazon EKS ne vous autorise pas à modifier le rôle lié à un service `AWSServiceRoleForAmazonEKSNodegroup`. Une fois que vous avez créé un rôle lié à un service, vous ne pouvez pas changer le nom du rôle, car plusieurs entités peuvent faire référence à ce rôle. Néanmoins, vous pouvez modifier la description du rôle à l’aide d’IAM. Pour plus d’informations, consultez [Modification d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) dans le *IAM Guide de l’utilisateur*.
## Suppression d'un rôle lié à un service pour Amazon EKS
Si vous n’avez plus besoin d’utiliser une fonctionnalité ou un service qui nécessite un rôle lié à un service, nous vous recommandons de supprimer ce rôle. De cette façon, vous n'avez aucune entité inutilisée qui n'est pas surveillée ou gérée activement. Cependant, vous devez nettoyer votre rôle lié à un service avant de pouvoir le supprimer manuellement.
### Nettoyer un rôle lié à un service
Avant de pouvoir utiliser IAM pour supprimer un rôle lié à un service, vous devez supprimer toutes les ressources utilisées par le rôle.
**Note**
Si le service Amazon EKS utilise le rôle lorsque vous essayez de supprimer les ressources, la suppression peut échouer. Si cela se produit, patientez quelques minutes et réessayez.
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dans le volet de navigation de gauche, choisissez **Clusters**.
1. Sélectionnez l'onglet **Compute** (Calcul).
1. Dans la section **Node Groups** (Groupes de nœuds), choisissez le groupe de nœuds à supprimer.
1. Tapez le nom du groupe de nœuds dans la fenêtre de confirmation de suppression, puis choisissez **Delete** (Supprimer).
1. Répétez cette procédure pour tous les autres groupes de nœuds du cluster. Attendez la fin de toutes les opérations de suppression.
### Suppression manuelle du rôle lié au service
Utilisez la console IAM, l'interface de ligne de commande AWS ou l'API AWS pour supprimer le rôle lié à un service `AWSServiceRoleForAmazonEKSNodegroup`. Pour plus d'informations, consultez [Suppression d'un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) dans le *Guide de l'utilisateur IAM*.
## Régions prises en charge pour les rôles liés à un service Amazon EKS
Amazon EKS prend en charge l'utilisation des rôles liés à un service dans toutes les régions où le service est disponible. Pour plus d'informations, consultez [Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html) (langue française non garantie).
# Utilisation de rôles pour les profils Amazon EKS Fargate
Amazon EKS utilise les [rôles liés au service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) de la gestion des identités et des accès AWS (IAM). Un rôle lié à un service est un type unique de rôle IAM lié directement à Amazon EKS. Les rôles liés à un service sont prédéfinis par Amazon EKS et incluent toutes les autorisations requises par le service pour appeler d'autres services AWS en votre nom.
Un rôle lié à un service facilite la configuration d’Amazon EKS, car vous n’avez pas à ajouter manuellement les autorisations nécessaires. Amazon EKS définit les autorisations de ses rôles liés à un service ; sauf définition contraire, seul Amazon EKS peut endosser ses rôles. Les autorisations définies comprennent la politique d'approbation et la politique d'autorisation. De plus, cette politique d'autorisation ne peut pas être attachée à une autre entité IAM.
Vous pouvez supprimer un rôle lié à un service uniquement après la suppression préalable de ses ressources connexes. Vos ressources Amazon EKS sont ainsi protégées, car vous ne pouvez pas involontairement supprimer l’autorisation d’accéder aux ressources.
Pour plus d'informations sur les autres services prenant en charge les rôles liés à un service, consultez les services [AWS opérationnels avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) et recherchez les services présentant la mention **Yes** (Oui) dans la colonne **Service-linked roles** (Rôles liés à un service). Choisissez un **Yes (oui)** ayant un lien permettant de consulter les détails du rôle pour ce service.
## Autorisations du rôle lié à un service pour Amazon EKS
Amazon EKS utilise le rôle lié à un service nommé `AWSServiceRoleForAmazonEKSForFargate`. Ce rôle permet à Amazon EKS Fargate de configurer le réseau VPC requis pour les pods Fargate. Les politiques attachées permettent au rôle de créer et de supprimer des interfaces réseau Elastic et de décrire les interfaces et les ressources réseau Elastic.
Le rôle lié à un service `AWSServiceRoleForAmazonEKSForFargate` approuve les services suivants pour endosser le rôle :
+ `eks-fargate.amazonaws.com`
La politique d'autorisations liée au rôle permet à Amazon EKS de réaliser les actions suivantes sur les ressources spécifiées :
+ [AmazonEKSForFargateServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSForFargateServiceRolePolicy.html)
Vous devez configurer les autorisations de manière à permettre à une entité IAM (comme un utilisateur, un groupe ou un rôle) de créer, modifier ou supprimer un rôle lié à un service. Pour plus d'informations, consultez [Autorisations de rôles liés à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dans le *Guide de l'utilisateur IAM*.
## Création d'un rôle lié à un service pour Amazon EKS
Vous n’avez pas besoin de créer manuellement un rôle lié à un service. Lorsque vous créez un profil Fargate dans la AWS Management Console, l’AWS CLI ou l’API AWS, Amazon EKS crée le rôle lié à un service pour vous.
**Important**
Ce rôle lié à un service peut apparaître dans votre compte si vous avez effectué une action dans un autre service qui utilise les fonctions prises en charge par ce rôle. Si vous utilisiez le service Amazon EKS avant le 13 décembre 2019, date à laquelle il a commencé à prendre en charge les rôles liés à un service, Amazon EKS a créé le rôle AWSServiceRoleForAmazonEKSForFargate dans votre compte. Pour plus d'informations, consultez [Un nouveau rôle est apparu dans mon compte IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).
### Création d'un rôle lié à un service dans Amazon EKS (API AWS)
Vous n’avez pas besoin de créer manuellement un rôle lié à un service. Lorsque vous créez un profil Fargate dans la AWS Management Console, l’AWS CLI ou l’API AWS, Amazon EKS crée le rôle lié à un service pour vous.
Si vous supprimez ce rôle lié à un service et que vous avez ensuite besoin de le recréer, vous pouvez utiliser la même procédure pour recréer le rôle dans votre compte. Lorsque vous créez un autre groupe de nœuds gérés, Amazon EKS crée automatiquement le rôle lié au service.
## Modification d'un rôle lié à un service pour Amazon EKS
Amazon EKS ne vous autorise pas à modifier le rôle lié à un service `AWSServiceRoleForAmazonEKSForFargate`. Une fois que vous avez créé un rôle lié à un service, vous ne pouvez pas changer le nom du rôle, car plusieurs entités peuvent faire référence à ce rôle. Néanmoins, vous pouvez modifier la description du rôle à l’aide d’IAM. Pour plus d’informations, consultez [Modification d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) dans le *IAM Guide de l’utilisateur*.
## Suppression d'un rôle lié à un service pour Amazon EKS
Si vous n’avez plus besoin d’utiliser une fonctionnalité ou un service qui nécessite un rôle lié à un service, nous vous recommandons de supprimer ce rôle. De cette façon, vous n'avez aucune entité inutilisée qui n'est pas surveillée ou gérée activement. Cependant, vous devez nettoyer votre rôle lié à un service avant de pouvoir le supprimer manuellement.
### Nettoyer un rôle lié à un service
Avant de pouvoir utiliser IAM pour supprimer un rôle lié à un service, vous devez supprimer toutes les ressources utilisées par le rôle.
**Note**
Si le service Amazon EKS utilise le rôle lorsque vous essayez de supprimer les ressources, la suppression peut échouer. Si cela se produit, patientez quelques minutes et réessayez.
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dans le volet de navigation de gauche, choisissez **Clusters**.
1. Sur la page **Clusters**, sélectionnez votre cluster.
1. Sélectionnez l'onglet **Compute** (Calcul).
1. S'il existe des profils Fargate dans la section **Profils Fargate**, sélectionnez chacun individuellement, puis choisissez **Delete** (Supprimer).
1. Tapez le nom du profile dans la fenêtre de confirmation de suppression, puis choisissez **Delete** (Supprimer).
1. Répétez cette procédure pour tous les autres profils Fargate dans le cluster et pour tous les autres clusters de votre compte.
### Suppression manuelle du rôle lié au service
Utilisez la console IAM, l’AWS CLI ou l’API AWS pour supprimer le rôle lié à un service AWSServiceRoleForAmazonEKSForFargate. Pour plus d'informations, consultez [Suppression d'un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) dans le *Guide de l'utilisateur IAM*.
## Régions prises en charge pour les rôles liés à un service Amazon EKS
Amazon EKS prend en charge l'utilisation des rôles liés à un service dans toutes les régions où le service est disponible. Pour plus d'informations, consultez [Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html) (langue française non garantie).
# Utilisation de rôles pour connecter un cluster Kubernetes à Amazon EKS
[Amazon EKS utilise des AWS rôles liés au service Identity and Access Management (IAM).](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) Un rôle lié à un service est un type unique de rôle IAM lié directement à Amazon EKS. Les rôles liés à un service sont prédéfinis par Amazon EKS et incluent toutes les autorisations requises par le service pour appeler d'autres AWS services en votre nom.
Un rôle lié à un service facilite la configuration d’Amazon EKS, car vous n’avez pas à ajouter manuellement les autorisations nécessaires. Amazon EKS définit les autorisations de ses rôles liés à un service ; sauf définition contraire, seul Amazon EKS peut endosser ses rôles. Les autorisations définies comprennent la politique d'approbation et la politique d'autorisation. De plus, cette politique d'autorisation ne peut pas être attachée à une autre entité IAM.
Vous pouvez supprimer un rôle lié à un service uniquement après la suppression préalable de ses ressources connexes. Vos ressources Amazon EKS sont ainsi protégées, car vous ne pouvez pas involontairement supprimer l’autorisation d’accéder aux ressources.
Pour plus d'informations sur les autres services prenant en charge les rôles liés à un service, consultez les services [AWS opérationnels avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) et recherchez les services présentant la mention **Yes** (Oui) dans la colonne **Service-linked roles** (Rôles liés à un service). Choisissez un **Oui** ayant un lien permettant de consulter les détails du rôle pour ce service.
## Autorisations du rôle lié à un service pour Amazon EKS
Amazon EKS utilise le rôle lié à un service nommé `AWSServiceRoleForAmazonEKSConnector`. Ce rôle permet à Amazon EKS de connecter des clusters Kubernetes. Les politiques associées permettent au rôle de gérer les ressources nécessaires pour se connecter à votre cluster Kubernetes enregistré.
Le rôle lié à un service `AWSServiceRoleForAmazonEKSConnector` approuve les services suivants pour endosser le rôle :
+ `eks-connector.amazonaws.com`
La politique d'autorisations liée au rôle permet à Amazon EKS de réaliser les actions suivantes sur les ressources spécifiées :
+ [AmazonEKSConnectorServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSConnectorServiceRolePolicy.html)
Vous devez configurer les autorisations de manière à permettre à une entité IAM (comme un utilisateur, un groupe ou un rôle) de créer, modifier ou supprimer un rôle lié à un service. Pour plus d’informations, consultez [Autorisations de rôles liés à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dans le *Guide de l’utilisateur IAM*.
Ce rôle utilise les autorisations SSM (Systems Manager) pour établir des connexions sécurisées et gérer les clusters Kubernetes connectés.
## Création d'un rôle lié à un service pour Amazon EKS
Il n’est pas nécessaire de créer manuellement un rôle lié à un service pour connecter un cluster. Lorsque vous connectez un cluster dans la AWS Management Console AWS CLI ou l' AWS API`eksctl`, Amazon EKS crée le rôle lié au service pour vous.
Si vous supprimez ce rôle lié à un service et que vous avez ensuite besoin de le recréer, vous pouvez utiliser la même procédure pour recréer le rôle dans votre compte. Lorsque vous connectez un cluster, Amazon EKS crée à nouveau le rôle lié à un service pour vous.
## Modification d'un rôle lié à un service pour Amazon EKS
Amazon EKS ne vous autorise pas à modifier le rôle lié à un service `AWSServiceRoleForAmazonEKSConnector`. Après avoir créé un rôle lié à un service, vous ne pouvez pas changer le nom du rôle, car plusieurs entités peuvent faire référence à ce rôle. Néanmoins, vous pouvez modifier la description du rôle à l’aide d’IAM. Pour plus d’informations, consultez [Modification d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) dans le *Guide de l’utilisateur IAM*.
## Suppression d'un rôle lié à un service pour Amazon EKS
Si vous n’avez plus besoin d’utiliser une fonctionnalité ou un service qui nécessite un rôle lié à un service, nous vous recommandons de supprimer ce rôle. De cette façon, vous n'avez aucune entité inutilisée qui n'est pas surveillée ou gérée activement. Cependant, vous devez nettoyer votre rôle lié à un service avant de pouvoir le supprimer manuellement.
### Nettoyage d’un rôle lié à un service
Avant de pouvoir utiliser IAM pour supprimer un rôle lié à un service, vous devez supprimer toutes les ressources utilisées par le rôle.
**Note**
Si le service Amazon EKS utilise le rôle lorsque vous essayez de supprimer les ressources, la suppression peut échouer. Si cela se produit, patientez quelques minutes et réessayez.
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dans le volet de navigation de gauche, choisissez **Clusters**.
1. Sur la page **Clusters**, sélectionnez votre cluster.
1. Sélectionnez les onglets **Annuler l'inscription** puis **Ok**.
### Suppression manuelle du rôle lié au service
Utilisez la console IAM, la AWS CLI ou l' AWS API pour supprimer le rôle lié au AWSService RoleForAmazon EKSConnector service. Pour plus d’informations, consultez la section [Suppression d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) dans le *Guide de l’utilisateur IAM*.
# Utilisation de rôles pour les clusters locaux Amazon EKS sur Outpost
Amazon Elastic Kubernetes Service utilise les [rôles liés au service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) Gestion des identités et des accès AWS (IAM). Un rôle lié à un service est un type unique de rôle IAM lié directement à Amazon EKS. Les rôles liés à un service sont prédéfinis par Amazon EKS et incluent toutes les autorisations requises par le service pour appeler d'autres services AWS en votre nom.
Un rôle lié à un service facilite la configuration d’Amazon EKS, car vous n’avez pas à ajouter manuellement les autorisations nécessaires. Amazon EKS définit les autorisations de ses rôles liés à un service ; sauf définition contraire, seul Amazon EKS peut endosser ses rôles. Les autorisations définies comprennent la politique d'approbation et la politique d'autorisation. De plus, cette politique d'autorisation ne peut pas être attachée à une autre entité IAM.
Vous pouvez supprimer un rôle lié à un service uniquement après la suppression préalable de ses ressources connexes. Vos ressources Amazon EKS sont ainsi protégées, car vous ne pouvez pas involontairement supprimer l’autorisation d’accéder aux ressources.
Pour plus d'informations sur les autres services prenant en charge les rôles liés à un service, consultez les services [AWS opérationnels avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) et recherchez les services présentant la mention **Yes** (Oui) dans la colonne **Service-linked roles** (Rôles liés à un service). Choisissez un **Yes (oui)** ayant un lien permettant de consulter les détails du rôle pour ce service.
## Autorisations du rôle lié à un service pour Amazon EKS
Amazon EKS utilise le rôle lié à un service nommé `AWSServiceRoleForAmazonEKSLocalOutpost`. Ce rôle permet à Amazon EKS de gérer les clusters locaux de votre compte. Les politiques attachées permettent au rôle de gérer les ressources suivantes : interfaces réseau, groupes de sécurité, journaux et instances Amazon EC2.
**Note**
Le rôle lié à un service `AWSServiceRoleForAmazonEKSLocalOutpost` est distinct du rôle requis pour la création de cluster. Pour de plus amples informations, consultez [Rôle IAM de cluster Amazon EKS](cluster-iam-role.md).
Le rôle lié à un service `AWSServiceRoleForAmazonEKSLocalOutpost` approuve les services suivants pour endosser le rôle :
+ `outposts.eks-local.amazonaws.com`
La politique d'autorisations liée au rôle permet à Amazon EKS de réaliser les actions suivantes sur les ressources spécifiées :
+ [AmazonEKSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html)
Vous devez configurer les autorisations de manière à permettre à une entité IAM (comme un utilisateur, un groupe ou un rôle) de créer, modifier ou supprimer un rôle lié à un service. Pour plus d'informations, consultez [Autorisations de rôles liés à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dans le *Guide de l'utilisateur IAM*.
## Création d'un rôle lié à un service pour Amazon EKS
Vous n’avez pas besoin de créer manuellement un rôle lié à un service. Lorsque vous créez un cluster dans la AWS Management Console, AWS CLI ou l’AWS API, Amazon EKS crée le rôle lié à un service pour vous.
Si vous supprimez ce rôle lié à un service et que vous avez ensuite besoin de le recréer, vous pouvez utiliser la même procédure pour recréer le rôle dans votre compte. Lorsque vous créez un cluster, Amazon EKS crée automatiquement le rôle lié au service à nouveau.
## Modification d'un rôle lié à un service pour Amazon EKS
Amazon EKS ne vous autorise pas à modifier le rôle lié à un service `AWSServiceRoleForAmazonEKSLocalOutpost`. Une fois que vous avez créé un rôle lié à un service, vous ne pouvez plus modifier son nom, car diverses entités peuvent y faire référence. Néanmoins, vous pouvez modifier la description du rôle à l’aide d’IAM. Pour plus d’informations, consultez [Modification d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) dans le *IAM Guide de l’utilisateur*.
## Suppression d'un rôle lié à un service pour Amazon EKS
Si vous n’avez plus besoin d’utiliser une fonctionnalité ou un service qui nécessite un rôle lié à un service, nous vous recommandons de supprimer ce rôle. De cette façon, vous n'avez aucune entité inutilisée qui n'est pas surveillée ou gérée activement. Cependant, vous devez nettoyer votre rôle lié à un service avant de pouvoir le supprimer manuellement.
### Nettoyer un rôle lié à un service
Avant de pouvoir utiliser IAM pour supprimer un rôle lié à un service, vous devez supprimer toutes les ressources utilisées par le rôle.
**Note**
Si le service Amazon EKS utilise le rôle lorsque vous essayez de supprimer les ressources, la suppression peut échouer. Si cela se produit, patientez quelques minutes et réessayez.
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Sélectionnez **Amazon EKS Clusters** (Clusters Amazon EKS) dans le panneau de navigation de gauche.
1. Si votre cluster possède des groupes de nœuds ou des profils Fargate, vous devez les supprimer avant de pouvoir supprimer le cluster. Pour plus d’informations, consultez [Supprimer un groupe de nœuds gérés de votre cluster](delete-managed-node-group.md) et [Supprimer un profil Fargate](delete-fargate-profile.md).
1. Dans la page **Clusters**, choisissez le cluster à supprimer et cliquez sur **Delete** (Supprimer).
1. Tapez le nom du cluster dans la fenêtre de confirmation de suppression, puis choisissez **Delete** (Supprimer).
1. Répétez cette procédure pour tous les autres clusters de votre compte. Attendez la fin de toutes les opérations de suppression.
### Suppression manuelle du rôle lié au service
Utilisez la console IAM, l'interface de ligne de commande AWS ou l'API AWS pour supprimer le rôle lié à un service `AWSServiceRoleForAmazonEKSLocalOutpost`. Pour plus d'informations, consultez [Suppression d'un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) dans le *Guide de l'utilisateur IAM*.
## Régions prises en charge pour les rôles liés à un service Amazon EKS
Amazon EKS prend en charge l'utilisation des rôles liés à un service dans toutes les régions où le service est disponible. Pour plus d'informations, consultez [Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html) (langue française non garantie).
# Utilisation des rôles pour le tableau de bord Amazon EKS
Le tableau de bord Amazon EKS utilise ce rôle lié à un service pour agréger les informations sur les ressources du cluster provenant de plusieurs régions et comptes. Le tableau de bord s’intègre à AWS Organizations pour lire en toute sécurité les informations relatives à plusieurs comptes de votre organisation.
Pour en savoir plus sur le tableau de bord Amazon EKS, consultez [Affichage des données agrégées des ressources du cluster dans le tableau de bord EKS](cluster-dashboard.md).
## Contexte
Amazon EKS utilise les [rôles liés au service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) de la gestion des identités et des accès AWS (IAM). Un rôle lié à un service est un type unique de rôle IAM lié directement à Amazon EKS. Les rôles liés à un service sont prédéfinis par Amazon EKS et incluent toutes les autorisations requises par le service pour appeler d'autres services AWS en votre nom.
Un rôle lié à un service facilite la configuration d’Amazon EKS, car vous n’avez pas à ajouter manuellement les autorisations nécessaires. Amazon EKS définit les autorisations de ses rôles liés à un service ; sauf définition contraire, seul Amazon EKS peut endosser ses rôles. Les autorisations définies comprennent la politique d'approbation et la politique d'autorisation. De plus, cette politique d'autorisation ne peut pas être attachée à une autre entité IAM.
Vous pouvez supprimer un rôle lié à un service uniquement après la suppression préalable de ses ressources connexes. Vos ressources Amazon EKS sont ainsi protégées, car vous ne pouvez pas involontairement supprimer l’autorisation d’accéder aux ressources.
Pour plus d'informations sur les autres services prenant en charge les rôles liés à un service, consultez les services [AWS opérationnels avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) et recherchez les services présentant la mention **Yes** (Oui) dans la colonne **Service-linked roles** (Rôles liés à un service). Choisissez un **Yes (oui)** ayant un lien permettant de consulter les détails du rôle pour ce service.
## Autorisations du rôle lié à un service pour Amazon EKS
Amazon EKS utilise le rôle lié à un service nommé `AWSServiceRoleForAmazonEKSDashboard`. Ce rôle permet à Amazon EKS de générer et d’afficher le tableau de bord Amazon EKS, y compris les informations agrégées sur les ressources du cluster. La politique `AmazonEKSDashboardServiceRolePolicy` attachée permet au rôle de gérer les ressources suivantes : groupes Auto Scaling, groupes de sécurité, modèles de lancement et profils d’instance IAM. Pour de plus amples informations, consultez [AWS politique gérée : Amazon EKSDashboard ServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSDashboardServiceRolePolicy).
Le rôle lié à un service `AWSServiceRoleForAmazonEKSDashboard` approuve les services suivants pour endosser le rôle :
+ `dashboard.eks.amazonaws.com`
Pour consulter la dernière version du document de politique JSON, consultez [AmazonEKSDashboardServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardServiceRolePolicy.html#AmazonEKSDashboardServiceRolePolicy-json) dans le guide de référence des politiques gérées par AWS.
Vous devez configurer les autorisations de manière à permettre à une entité IAM (comme un utilisateur, un groupe ou un rôle) de créer, modifier ou supprimer un rôle lié à un service. Pour plus d'informations, consultez [Autorisations de rôles liés à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dans le *Guide de l'utilisateur IAM*.
## Création d'un rôle lié à un service pour Amazon EKS
Vous n’avez pas besoin de créer manuellement un rôle lié à un service. Lorsque vous activez le tableau de bord dans la console AWS, Amazon EKS crée le rôle lié à un service pour vous.
Pour plus d’informations sur l’activation du tableau de bord EKS, consultez [Configurer l'intégration du tableau de bord EKS avec les AWS Organizations](cluster-dashboard-orgs.md).
**Important**
Ce rôle lié à un service peut apparaître dans votre compte si vous avez effectué une action dans un autre service qui utilise les fonctions prises en charge par ce rôle.
## Modification d'un rôle lié à un service pour Amazon EKS
Amazon EKS ne vous autorise pas à modifier le rôle lié à un service `AWSServiceRoleForAmazonEKSDashboard`. Une fois que vous avez créé un rôle lié à un service, vous ne pouvez pas changer le nom du rôle, car plusieurs entités peuvent faire référence à ce rôle. Néanmoins, vous pouvez modifier la description du rôle à l’aide d’IAM. Pour plus d’informations, consultez [Modification d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) dans le *IAM Guide de l’utilisateur*.
## Suppression d'un rôle lié à un service pour Amazon EKS
Si vous n’avez plus besoin d’utiliser une fonctionnalité ou un service qui nécessite un rôle lié à un service, nous vous recommandons de supprimer ce rôle. De cette façon, vous n'avez aucune entité inutilisée qui n'est pas surveillée ou gérée activement. Cependant, vous devez nettoyer votre rôle lié à un service avant de pouvoir le supprimer manuellement.
### Nettoyer un rôle lié à un service
Avant de pouvoir utiliser IAM pour supprimer un rôle lié à un service, vous devez supprimer toutes les ressources utilisées par le rôle.
**Note**
Si le service Amazon EKS utilise le rôle lorsque vous essayez de supprimer les ressources, la suppression peut échouer. Si cela se produit, patientez quelques minutes et réessayez.
Pour plus d’informations sur la désactivation du tableau de bord EKS, consultez [Configurer l'intégration du tableau de bord EKS avec les AWS Organizations](cluster-dashboard-orgs.md).
### Suppression manuelle du rôle lié au service
Utilisez la console IAM, l'interface de ligne de commande AWS ou l'API AWS pour supprimer le rôle lié à un service `AWSServiceRoleForAmazonEKSDashboard`. Pour plus d'informations, consultez [Suppression d'un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) dans le *Guide de l'utilisateur IAM*.
## Régions prises en charge pour les rôles liés à un service Amazon EKS
Amazon EKS prend en charge l'utilisation des rôles liés à un service dans toutes les régions où le service est disponible. Pour plus d'informations, consultez [Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html) (langue française non garantie).
# Rôle IAM d’exécution de pod Amazon EKS
Le rôle d'exécution Amazon EKS Pod est requis pour exécuter des pods sur l'infrastructure AWS Fargate.
Lorsque votre cluster crée des pods sur l'infrastructure AWS Fargate, les composants exécutés sur l'infrastructure Fargate doivent effectuer des appels en votre nom. AWS APIs Cela leur permet d'effectuer des actions telles que l'extraction d'images de conteneurs depuis Amazon ECR ou le routage des journaux vers d'autres AWS services. Pour ce faire, le rôle d’exécution de pod Amazon EKS fournit les autorisations IAM.
Lorsque vous créez un profil Fargate, vous devez spécifier un rôle d’exécution de pod pour les composants Amazon EKS qui s’exécutent sur l’infrastructure Fargate à l’aide du profil. Ce rôle est ajouté au [Contrôle d’accès basé sur les rôles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) Kubernetes du cluster à des fins d’autorisation. Cela permet au `kubelet` qui s’exécute sur l’infrastructure Fargate de s’enregistrer auprès de votre cluster Amazon EKS afin qu’il puisse apparaître dans votre cluster en tant que nœud.
**Note**
Le profil Fargate doit avoir un rôle IAM différent de celui EC2 des groupes de nœuds Amazon.
**Important**
Les conteneurs s’exécutant dans le pod Fargate ne peuvent pas assumer les autorisations IAM associées à un rôle d’exécution de pod. Pour autoriser les conteneurs de votre Fargate Pod à accéder à d' AWS autres services, vous devez [utiliser des rôles IAM](iam-roles-for-service-accounts.md) pour les comptes de service.
[Avant de créer un profil Fargate, vous devez créer un rôle IAM auprès d'Amazon. EKSFargate PodExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSFargatePodExecutionRolePolicy.html)
## Vérifiez si un rôle d’exécution de pod existant est correctement configuré
Vous pouvez suivre la procédure suivante pour vérifier si votre compte dispose déjà d’un rôle d’exécution de pod Amazon EKS correctement configuré. Afin d’éviter tout problème de sécurité lié à un délégué confus, il est important que le rôle restreigne l’accès en fonction de `SourceArn`. Vous pouvez modifier le rôle d'exécution si nécessaire pour inclure la prise en charge des profils Fargate sur d'autres clusters.
1. Ouvrez la console IAM à https://console.aws.amazon.com/iam/ l'adresse.
1. Dans le volet de navigation de gauche, choisissez **Rôles**.
1. Sur la page **Rôles**, recherchez la liste des rôles pour **Amazon EKSFargate PodExecutionRole**. Si le rôle n’existe pas, consultez [Création du rôle d’exécution de pod Amazon EKS](#create-pod-execution-role) pour créer le rôle. Si le rôle existe, sélectionnez-le.
1. Sur la EKSFargate PodExecutionRole page **Amazon**, procédez comme suit :
1. Choisissez **Autorisations**.
1. Assurez-vous que la politique gérée par **EKSFargatePodExecutionRolePolicyAmazon** est attachée au rôle.
1. Choisissez **Trust Relationships** (Relations d'approbation).
1. Choisissez **Edit trust policy** (Modifier la politique).
1. Dans la page **Edit trust policy** (Modifier la politique), vérifiez que la relation d'approbation contient la politique suivante, ainsi qu'une ligne pour les profils Fargate sur votre cluster. Dans ce cas, sélectionnez **Cancel** (Annuler).
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*"
}
},
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
Si la politique correspond mais ne comporte pas de ligne spécifiant les profils Fargate sur votre cluster, vous pouvez ajouter la ligne suivante en haut de l’objet `ArnLike`. Remplacez *region-code* par la AWS région dans laquelle se trouve votre cluster, *111122223333* par votre identifiant de compte et *my-cluster* par le nom de votre cluster.
```
"aws:SourceArn": "arn:aws: eks:region-code:111122223333:fargateprofile/my-cluster/*",
```
Si la politique ne correspond pas, copiez l’intégralité de la politique précédente dans le formulaire et sélectionnez **Mettre à jour la politique**. Remplacez *region-code* par la AWS région dans laquelle se trouve votre cluster. Si vous souhaitez utiliser le même rôle dans toutes les AWS régions de votre compte, remplacez *region-code* par`*`. Remplacez *111122223333* par l'ID de votre compte et *my-cluster* par le nom de votre cluster. Si vous souhaitez utiliser le même rôle pour tous les clusters de votre compte, remplacez *my-cluster* par `*`.
## Création du rôle d’exécution de pod Amazon EKS
Si vous ne possédez pas encore le rôle d'exécution Amazon EKS Pod pour votre cluster, vous pouvez utiliser la AWS Management Console ou la AWS CLI pour le créer.
AWS Management Console
1. Ouvrez la console IAM à https://console.aws.amazon.com/iam/ l'adresse.
1. Dans le volet de navigation de gauche, choisissez **Rôles**.
1. Sur la page **Rôles**, choisissez **Créer un rôle**.
1. Sur la page **Select trusted entity** (Sélectionner une entité de confiance), procédez comme suit :
1. Dans la section **Type d'entité fiable**, sélectionnez ** AWS service**.
1. Dans la liste déroulante **Cas d'utilisation d'autres AWS services**, sélectionnez **EKS**.
1. Sélectionnez **EKS – Fargate Pod**.
1. Choisissez **Suivant**.
1. Sur la page **Add permissions** (Ajouter des autorisations), sélectionnez **Next** (Suivant).
1. Sur la page **Name, review, and create** (Nommer, vérifier et créer), procédez comme suit :
1. Pour **Role name** (Nom de rôle), saisissez un nom unique pour votre rôle, par exemple, `AmazonEKSFargatePodExecutionRole`.
1. Sous **Ajouter des balises (Facultatif)**, ajoutez des métadonnées au rôle en attachant les identifications sous forme de paires clé-valeur. Pour plus d'informations sur l'utilisation des balises dans IAM, consultez la rubrique [Balisage des ressources IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) dans le *Guide de l'utilisateur IAM*.
1. Choisissez **Créer un rôle**.
1. Sur la page **Rôles**, recherchez la liste des rôles pour **Amazon EKSFargate PodExecutionRole**. Choisissez le rôle.
1. Sur la EKSFargate PodExecutionRole page **Amazon**, procédez comme suit :
1. Choisissez **Trust Relationships** (Relations d'approbation).
1. Choisissez **Edit trust policy** (Modifier la politique).
1. Dans la page **Edit trust policy** (Modifier la politique), procédez comme suit :
1. Copiez le contenu suivant et collez-le dans le formulaire **Edit trust policy** (Modifier la politique). Remplacez *region-code* par la AWS région dans laquelle se trouve votre cluster. Si vous souhaitez utiliser le même rôle dans toutes les AWS régions de votre compte, remplacez *region-code* par`*`. Remplacez *111122223333* par l'ID de votre compte et *my-cluster* par le nom de votre cluster. Si vous souhaitez utiliser le même rôle pour tous les clusters de votre compte, remplacez *my-cluster* par `*`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*"
}
},
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Choisissez **Mettre à jour une politique**.
AWS CLI
1. Copiez le contenu suivant et collez-le dans un fichier nommé `pod-execution-role-trust-policy.json`. Remplacez *region-code* par la AWS région dans laquelle se trouve votre cluster. Si vous souhaitez utiliser le même rôle dans toutes les AWS régions de votre compte, remplacez *region-code* par`*`. Remplacez *111122223333* par l'ID de votre compte et *my-cluster* par le nom de votre cluster. Si vous souhaitez utiliser le même rôle pour tous les clusters de votre compte, remplacez *my-cluster* par `*`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*"
}
},
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Créez un rôle IAM d’exécution de pod.
```
aws iam create-role \
--role-name AmazonEKSFargatePodExecutionRole \
--assume-role-policy-document file://"pod-execution-role-trust-policy.json"
```
1. Attachez la politique IAM gérée par Amazon EKS au rôle.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSFargatePodExecutionRolePolicy \
--role-name AmazonEKSFargatePodExecutionRole
```
# Rôle IAM du connecteur Amazon EKS
Vous pouvez connecter des clusters Kubernetes pour les afficher dans votre. AWS Management Console Pour vous connecter à un cluster Kubernetes, créez un rôle IAM.
## Rechercher un rôle de connecteur EKS existant
Vous pouvez utiliser la procédure suivante pour vérifier si votre compte possède déjà le rôle de connecteur Amazon EKS.
1. Ouvrez la console IAM à https://console.aws.amazon.com/iam/ l'adresse.
1. Dans le volet de navigation de gauche, choisissez **Rôles**.
1. Recherchez dans la liste des rôles `AmazonEKSConnectorAgentRole`. Si un rôle qui inclut `AmazonEKSConnectorAgentRole` n’existe pas, consultez [Création du rôle de l'agent Amazon EKS Connector](#create-connector-role) pour créer le rôle. Si un rôle qui inclut `AmazonEKSConnectorAgentRole` existe, sélectionnez le rôle pour afficher les politiques attachées.
1. Choisissez **Permissions (Autorisations)**.
1. Assurez-vous que la politique EKSConnector AgentPolicy gérée par **Amazon** est attachée au rôle. Si la politique est attachée, votre rôle de connecteur Amazon EKS est configuré correctement.
1. Sélectionnez l'onglet **Trust relationships** (Relations d'approbation), puis **Edit trust policy** (Modifier la relation d'approbation).
1. Vérifiez que la relation d'approbation contient la politique suivante. Si la relation d'approbation correspond à la politique ci-dessous, sélectionnez **Annuler**. Si la relation d’approbation ne correspond pas, copiez la politique dans la fenêtre **Modifier la politique d’approbation** et sélectionnez **Mettre à jour la politique**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"ssm.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
## Création du rôle de l'agent Amazon EKS Connector
Vous pouvez utiliser le AWS Management Console ou AWS CloudFormation pour créer le rôle d'agent du connecteur.
AWS CLI
1. Créez le fichier nommé `eks-connector-agent-trust-policy.json` qui contient le JSON suivant à utiliser pour le rôle IAM.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"ssm.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Créez le fichier nommé `eks-connector-agent-policy.json` qui contient le JSON suivant à utiliser pour le rôle IAM.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SsmControlChannel",
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel"
],
"Resource": "arn:aws:eks:*:*:cluster/*"
},
{
"Sid": "ssmDataplaneOperations",
"Effect": "Allow",
"Action": [
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenDataChannel",
"ssmmessages:OpenControlChannel"
],
"Resource": "*"
}
]
}
```
1. Créez le rôle d'agent Amazon EKS Connector à l'aide de la politique d'approbation et de la politique que vous avez créées dans les listes précédentes.
```
aws iam create-role \
--role-name AmazonEKSConnectorAgentRole \
--assume-role-policy-document file://eks-connector-agent-trust-policy.json
```
1. Attachez la politique à votre rôle d'agent Amazon EKS Connector.
```
aws iam put-role-policy \
--role-name AmazonEKSConnectorAgentRole \
--policy-name AmazonEKSConnectorAgentPolicy \
--policy-document file://eks-connector-agent-policy.json
```
AWS CloudFormation
1. Enregistrez le AWS CloudFormation modèle suivant dans un fichier texte sur votre système local.
**Note**
Ce modèle crée également le rôle lié à un service qui serait autrement créé lorsque l'API `registerCluster` est appelée. Consultez [Utilisation de rôles pour connecter un cluster Kubernetes à Amazon EKS](using-service-linked-roles-eks-connector.md) pour plus de détails.
```
---
AWSTemplateFormatVersion: '2010-09-09'
Description: 'Provisions necessary resources needed to register clusters in EKS'
Parameters: {}
Resources:
EKSConnectorSLR:
Type: AWS::IAM::ServiceLinkedRole
Properties:
AWSServiceName: eks-connector.amazonaws.com
EKSConnectorAgentRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action: [ 'sts:AssumeRole' ]
Principal:
Service: 'ssm.amazonaws.com'
EKSConnectorAgentPolicy:
Type: AWS::IAM::Policy
Properties:
PolicyName: EKSConnectorAgentPolicy
Roles:
- {Ref: 'EKSConnectorAgentRole'}
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: 'Allow'
Action: [ 'ssmmessages:CreateControlChannel' ]
Resource:
- Fn::Sub: 'arn:${AWS::Partition}:eks:*:*:cluster/*'
- Effect: 'Allow'
Action: [ 'ssmmessages:CreateDataChannel', 'ssmmessages:OpenDataChannel', 'ssmmessages:OpenControlChannel' ]
Resource: "*"
Outputs:
EKSConnectorAgentRoleArn:
Description: The agent role that EKS connector uses to communicate with AWS services.
Value: !GetAtt EKSConnectorAgentRole.Arn
```
1. Ouvrez la [AWS CloudFormation console](https://console.aws.amazon.com/cloudformation/).
1. Sélectionnez **Créer une pile** avec de nouvelles ressources (standard).
1. Pour **Specify template (Spécifier un modèle)**, sélectionnez **Upload a template file (Télécharger un fichier de modèle)**, puis choisissez **Choose file (Choisir un fichier)**.
1. Choisissez le fichier que vous avez créé précédemment, puis choisissez **Next (Suivant)**.
1. Pour **Stack name (Nom de la pile)**, saisissez un nom pour votre rôle, par exemple `eksConnectorAgentRole`, puis choisissez **Next (Suivant)**.
1. Sur la page **Configurer les options de pile**, choisissez ** Next (Suivant)**.
1. Sur la page **Vérification**, vérifiez vos informations, reconnaissez que la pile peut créer des ressources IAM, puis choisissez **Create stack (Créer la pile)**.
# AWS politiques gérées pour Amazon Elastic Kubernetes Service
Une politique AWS gérée est une politique autonome créée et administrée par AWS. AWS les politiques gérées sont conçues pour fournir des autorisations pour de nombreux cas d'utilisation courants afin que vous puissiez commencer à attribuer des autorisations aux utilisateurs, aux groupes et aux rôles.
N'oubliez pas que les politiques AWS gérées peuvent ne pas accorder d'autorisations de moindre privilège pour vos cas d'utilisation spécifiques, car elles sont accessibles à tous les AWS clients. Nous vous recommandons de réduire encore les autorisations en définissant des [politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) qui sont propres à vos cas d’utilisation.
Vous ne pouvez pas modifier les autorisations définies dans les politiques AWS gérées. Si les autorisations définies dans une politique AWS gérée sont AWS mises à jour, la mise à jour affecte toutes les identités principales (utilisateurs, groupes et rôles) auxquelles la politique est attachée. AWS est le plus susceptible de mettre à jour une politique AWS gérée lorsqu'un nouveau AWS service est lancé ou lorsque de nouvelles opérations d'API sont disponibles pour les services existants.
Pour plus d’informations, consultez [Politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) dans le *Guide de l’utilisateur IAM*.
## AWS politique gérée : Amazoneks\$1CNI\$1Policy
Vous pouvez attacher `AmazonEKS_CNI_Policy` à vos entités IAM. Avant de créer un groupe de nœuds Amazon EC2, cette politique doit être associée soit au [rôle IAM du nœud](create-node-role.md), soit à un rôle IAM utilisé spécifiquement par le plug-in CNI Amazon VPC pour Kubernetes. Ceci lui permet d'effectuer des actions en votre nom. Nous vous recommandons d’associer la politique à un rôle utilisé uniquement par le plug-in. Pour plus d’informations, consultez [Attribuer IPs à des pods avec l'Amazon VPC CNI](managing-vpc-cni.md) et [Configuration du plug-in Amazon VPC CNI pour utiliser IRSA](cni-iam-role.md).
**Détails de l'autorisation**
Cette politique inclut les autorisations suivantes qui permettent à Amazon EKS d'effectuer les tâches suivantes :
+ ** `ec2:*NetworkInterface` et `ec2:*PrivateIpAddresses` ** : permet au plug-in CNI Amazon VPC d’effectuer des actions telles que le provisionnement d’interfaces réseau Elastic et d’adresses IP pour les pods afin de fournir une mise en réseau pour les applications qui s’exécutent dans Amazon EKS.
+ **Actions de lecture `ec2`** : permet au plug-in CNI Amazon VPC d’effectuer des actions telles que la description d’instances et de sous-réseaux afin de connaître le nombre d’adresses IP libres dans vos sous-réseaux Amazon VPC. Le CNI VPC peut utiliser les adresses IP libres dans chaque sous-réseau pour sélectionner les sous-réseaux disposant du plus grand nombre d’adresses IP libres à utiliser lors de la création d’une interface réseau Elastic.
Pour consulter la dernière version du document de politique JSON, consultez [Amazoneks\$1CNI\$1Policy dans le Managed Policy Reference Guide](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html#AmazonEKS_CNI_Policy-json). AWS
## AWS politique gérée : Amazon EKSCluster Policy
Vous pouvez attacher `AmazonEKSClusterPolicy` à vos entités IAM. Avant de créer un cluster, vous devez disposer d'un [rôle IAM de cluster](cluster-iam-role.md) avec la politique ci-jointe. Les clusters Kubernetes gérés par Amazon EKS appellent d'autres AWS services en votre nom. Ils le font pour gérer les ressources que vous utilisez avec le service.
Cette politique inclut les autorisations suivantes qui permettent à Amazon EKS d'effectuer les tâches suivantes :
+ ** `autoscaling` ** : lit et met à jour la configuration d’un groupe Auto Scaling. Ces autorisations ne sont pas utilisées par Amazon EKS, mais restent dans la politique pour des raisons de compatibilité ascendante.
+ ** `ec2` ** : utilisez les volumes et les ressources réseau associés aux nœuds Amazon EC2. Ceci est nécessaire pour que le plan de contrôle Kubernetes puisse joindre des instances à un cluster et approvisionner et gérer dynamiquement les volumes Amazon EBS demandés par des volumes persistants Kubernetes.
+ ** `ec2` ** : supprimer les interfaces réseau Elastic créées par le CNI VPC. Cette opération est nécessaire pour permettre à EKS de nettoyer les interfaces réseau Elastic qui restent si le VPC CNI se ferme de manière inattendue.
+ ** `elasticloadbalancing` ** : utilisez les équilibreurs de charge Elastic et y ajouter des nœuds en tant que cibles. Ceci est nécessaire pour que le plan de contrôle Kubernetes puisse allouer de manière dynamique les Elastic Load Balancer demandés par les services Kubernetes.
+ ** `iam` ** : créez un rôle lié à un service. Ceci est nécessaire pour que le plan de contrôle Kubernetes puisse allouer de manière dynamique les Elastic Load Balancer demandés par les services Kubernetes.
+ **`kms`**— Lit une clé depuis AWS KMS. Cette condition est nécessaire pour que le plan de contrôle de Kubernetes prenne en charge le [chiffrement des secrets](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) Kubernetes stockés dans `etcd`.
Pour consulter la dernière version du document de politique JSON, consultez [Amazon EKSCluster Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json) dans le AWS Managed Policy Reference Guide.
## AWS politique gérée : Amazon EKSDashboard ConsoleReadOnly
Vous pouvez attacher `AmazonEKSDashboardConsoleReadOnly` à vos entités IAM.
Cette politique inclut les autorisations suivantes qui permettent à Amazon EKS d'effectuer les tâches suivantes :
+ ** `eks` ** : accès en lecture seule aux données du tableau de bord EKS, aux ressources et aux informations sur les versions du cluster. Cela permet de consulter les métriques liées à EKS et les détails de configuration du cluster.
+ **`organizations`**- Accès en lecture seule aux informations des AWS Organizations, notamment :
+ Affichage des détails de l’organisation et de l’accès aux services
+ Affichage de la liste des racines organisationnelles, des comptes et des unités organisationnelles
+ Affichage de la structure organisationnelle
Pour consulter la dernière version du document de politique JSON, consultez [Amazon EKSDashboard ConsoleReadOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardConsoleReadOnly.html#AmazonEKSDashboardConsoleReadOnly-json) dans le AWS Managed Policy Reference Guide.
## AWS politique gérée : Amazon EKSFargate PodExecutionRolePolicy
Vous pouvez attacher `AmazonEKSFargatePodExecutionRolePolicy` à vos entités IAM. Avant de pouvoir créer un profil Fargate, vous devez créer un rôle d’exécution de pod Fargate et y associer cette politique. Pour plus d’informations, consultez [Étape 2 : créer un rôle d’exécution Fargate Pod](fargate-getting-started.md#fargate-sg-pod-execution-role) et [Définissez quels pods utilisent AWS Fargate lors de leur lancement](fargate-profile.md).
Cette politique accorde au rôle les autorisations lui permettant d'accéder aux autres ressources de AWS service requises pour exécuter les pods Amazon EKS sur Fargate.
**Détails de l'autorisation**
Cette politique inclut les autorisations suivantes qui permettent à Amazon EKS d'effectuer les tâches suivantes :
+ ** `ecr` ** : permet aux pods qui s’exécutent sur Fargate d’extraire les images de conteneur stockées dans Amazon ECR.
Pour consulter la dernière version du document de politique JSON, consultez [Amazon EKSFargate PodExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSFargatePodExecutionRolePolicy.html#AmazonEKSFargatePodExecutionRolePolicy-json) dans le AWS Managed Policy Reference Guide.
## AWS politique gérée : Amazon EKSConnector ServiceRolePolicy
Vous ne pouvez pas associer `AmazonEKSConnectorServiceRolePolicy` à vos entités IAM. Cette politique est attachée à un rôle lié à un service qui permet à Amazon EKS d'effectuer des actions en votre nom. Pour de plus amples informations, veuillez consulter [Utilisation de rôles pour connecter un cluster Kubernetes à Amazon EKS](using-service-linked-roles-eks-connector.md).
Ce rôle permet à Amazon EKS de connecter des clusters Kubernetes. Les politiques associées permettent au rôle de gérer les ressources nécessaires pour se connecter à votre cluster Kubernetes enregistré.
**Détails de l'autorisation**
Cette politique inclut les autorisations suivantes qui permettent à Amazon EKS d'effectuer les tâches suivantes.
+ **`SSM Management`**— Créez, décrivez et supprimez les activations SSM, et annulez l'enregistrement des instances gérées. Cela permet les opérations de base de Systems Manager.
+ **`Session Management`**— Démarrez des sessions SSM spécifiquement pour les clusters EKS et exécutez des commandes non interactives à l'aide du document AmazoneKS.
+ **`IAM Role Passing`**— Transmettez les rôles IAM spécifiquement au service SSM, sous le contrôle d'une condition qui restreint les rôles transmis à. `ssm.amazonaws.com`
+ **`EventBridge Rules`**— Créez des EventBridge règles et des cibles, mais uniquement lorsque vous êtes géré par`eks-connector.amazonaws.com`. Les règles sont spécifiquement limitées au AWS SSM en tant que source d'événement.
Pour consulter la dernière version du document de politique JSON, consultez [Amazon EKSConnector ServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSConnectorServiceRolePolicy.html) dans le AWS Managed Policy Reference Guide.
## AWS politique gérée : Amazon EKSFor FargateServiceRolePolicy
Vous ne pouvez pas associer `AmazonEKSForFargateServiceRolePolicy` à vos entités IAM. Cette politique est attachée à un rôle lié à un service qui permet à Amazon EKS d'effectuer des actions en votre nom. Pour de plus amples informations, veuillez consulter `AWSServiceRoleforAmazonEKSForFargate`.
Cette politique accorde les autorisations nécessaires à Amazon EKS pour exécuter des tâches Fargate. La politique n'est utilisée que si vous avez des nœuds Fargate.
**Détails de l'autorisation**
Cette politique inclut les autorisations suivantes qui permettent à Amazon EKS d'effectuer les tâches suivantes.
+ ** `ec2` ** : créer et supprimer des interfaces réseau Elastic et décrire les interfaces réseau Elastic et les ressources. Ceci est nécessaire pour que le service Amazon EKS Fargate puisse configurer le réseau VPC requis pour les pods Fargate.
Pour consulter la dernière version du document de politique JSON, consultez [Amazon EKSFor FargateServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSForFargateServiceRolePolicy.html#AmazonEKSForFargateServiceRolePolicy-json) dans le AWS Managed Policy Reference Guide.
## AWS politique gérée : Amazon EKSCompute Policy
Vous pouvez attacher `AmazonEKSComputePolicy` à vos entités IAM. Vous pouvez associer cette politique à votre [rôle IAM du cluster](cluster-iam-role.md) afin d’étendre les ressources qu’EKS peut gérer dans votre compte.
Cette politique accorde les autorisations requises pour qu’Amazon EKS puisse créer et gérer des instances EC2 pour le cluster EKS, ainsi que les autorisations IAM nécessaires pour configurer EC2. De plus, cette politique accorde à Amazon EKS les autorisations nécessaires pour créer le rôle lié à un service EC2 Spot en votre nom.
### Détails de l'autorisation
Cette politique inclut les autorisations suivantes qui permettent à Amazon EKS d'effectuer les tâches suivantes :
+ ** Autorisations `ec2`** :
+ `ec2:CreateFleet` et `ec2:RunInstances` : permet de créer des instances EC2 et d’utiliser des ressources EC2 spécifiques (images, groupes de sécurité, sous-réseaux) pour les nœuds du cluster EKS.
+ `ec2:CreateLaunchTemplate` : permet de créer des modèles de lancement EC2 pour les nœuds du cluster EKS.
+ La politique comprend également des conditions visant à restreindre l’utilisation de ces autorisations EC2 aux ressources balisées avec le nom du cluster EKS et d’autres balises pertinentes.
+ `ec2:CreateTags` : permet de baliser les ressources EC2 créées par les actions `CreateFleet`, `RunInstances` et `CreateLaunchTemplate`.
+ ** Autorisations `iam`** :
+ `iam:AddRoleToInstanceProfile` : permet d’ajouter un rôle IAM au profil d’instance de calcul EKS.
+ `iam:PassRole` : permet de transmettre les rôles IAM nécessaires au service EC2.
Pour consulter la dernière version du document de politique JSON, consultez [Amazon EKSCompute Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSComputePolicy.html#AmazonEKSComputePolicy-json) dans le AWS Managed Policy Reference Guide.
## AWS politique gérée : Amazon EKSNetworking Policy
Vous pouvez attacher `AmazonEKSNetworkingPolicy` à vos entités IAM. Vous pouvez associer cette politique à votre [rôle IAM du cluster](cluster-iam-role.md) afin d’étendre les ressources qu’EKS peut gérer dans votre compte.
Cette politique est conçue pour accorder les autorisations nécessaires à Amazon EKS afin de créer et de gérer les interfaces réseau pour le cluster EKS, permettant ainsi au plan de contrôle et aux composants master de communiquer et de fonctionner correctement.
### Détails de l’autorisation
Cette politique accorde les autorisations suivantes pour permettre à Amazon EKS de gérer les interfaces réseau pour le cluster :
+ ** Autorisations d’interface réseau `ec2`** :
+ `ec2:CreateNetworkInterface` : permet de créer des interfaces réseau EC2.
+ La politique inclut des conditions visant à restreindre l’utilisation de cette autorisation aux interfaces réseau balisées avec le nom du cluster EKS et le nom du nœud CNI Kubernetes.
+ `ec2:CreateTags` : permet d’ajouter des balises aux interfaces réseau créées par l’action `CreateNetworkInterface`.
+ ** Autorisations de gestion de l’interface réseau `ec2`** :
+ `ec2:AttachNetworkInterface`,`ec2:ModifyNetworkInterfaceAttribute`, `ec2:DetachNetworkInterface` - Permet d'attacher, de modifier les attributs d'interface réseau et de détacher les interfaces réseau aux instances EC2.
+ `ec2:UnassignPrivateIpAddresses`, `ec2:UnassignIpv6Addresses`, `ec2:AssignPrivateIpAddresses`, `ec2:AssignIpv6Addresses` : permet de gérer les attributions d’adresses IP des interfaces réseau.
+ Ces autorisations sont limitées aux interfaces réseau balisées avec le nom du cluster Amazon EKS.
Pour consulter la dernière version du document de politique JSON, consultez [Amazon EKSNetworking Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSNetworkingPolicy.html#AmazonEKSNetworkingPolicy-json) dans le AWS Managed Policy Reference Guide.
## AWS politique gérée : Amazon EKSBlock StoragePolicy
Vous pouvez attacher `AmazonEKSBlockStoragePolicy` à vos entités IAM. Vous pouvez associer cette politique à votre [rôle IAM du cluster](cluster-iam-role.md) afin d’étendre les ressources qu’EKS peut gérer dans votre compte.
Cette politique accorde les autorisations nécessaires à Amazon EKS pour créer, gérer et maintenir des volumes EC2 et des instantanés pour le cluster Amazon EKS, permettant ainsi au plan de contrôle et aux composants master de provisionner et d’utiliser le stockage persistant selon les besoins des charges de travail Kubernetes.
### Détails de l’autorisation
Cette politique IAM accorde les autorisations suivantes pour permettre à Amazon EKS de gérer les volumes et les instantanés EC2 :
+ ** Autorisations de gestion des volumes `ec2` ** :
+ `ec2:AttachVolume`, `ec2:DetachVolume`, `ec2:ModifyVolume`, `ec2:EnableFastSnapshotRestores` : permet de connecter, déconnecter, modifier et activer la restauration rapide des instantanés pour les volumes EC2.
+ Ces autorisations sont limitées aux volumes balisés avec le nom du cluster EKS.
+ `ec2:CreateTags` : permet d’ajouter des balises aux volumes EC2 et aux instantanés créés par les actions `CreateVolume` et `CreateSnapshot`.
+ ** Autorisations de création de volume `ec2`** :
+ `ec2:CreateVolume` : permet de créer de nouveaux volumes EC2.
+ La politique comprend des conditions qui limitent l’utilisation de cette autorisation aux volumes balisés avec le nom du cluster EKS et d’autres balises pertinentes.
+ `ec2:CreateSnapshot` : permet de créer de nouveaux instantanés de volume EC2.
+ La politique comprend des conditions qui limitent l’utilisation de cette autorisation aux instantanés balisés avec le nom du cluster EKS et d’autres balises pertinentes.
Pour consulter la dernière version du document de politique JSON, consultez [Amazon EKSBlock StoragePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSBlockStoragePolicy.html#AmazonEKSBlockStoragePolicy-json) dans le AWS Managed Policy Reference Guide.
## AWS politique gérée : Amazon EKSLoad BalancingPolicy
Vous pouvez attacher `AmazonEKSLoadBalancingPolicy` à vos entités IAM. Vous pouvez associer cette politique à votre [rôle IAM du cluster](cluster-iam-role.md) afin d’étendre les ressources qu’EKS peut gérer dans votre compte.
Cette politique IAM accorde les autorisations nécessaires à Amazon EKS pour travailler avec différents AWS services afin de gérer les Elastic Load Balancers (ELBs) et les ressources associées.
### Détails de l’autorisation
Les principales autorisations accordées par cette politique sont les suivantes :
+ ** `elasticloadbalancing` ** : permet de créer, modifier et gérer des Elastic Load Balancers et des groupes cibles. Cela inclut les autorisations de créer, mettre à jour et supprimer des équilibreurs de charge, des groupes cibles, des écouteurs et des règles.
+ ** `ec2` ** : permet de créer et de gérer des groupes de sécurité, qui sont nécessaires au plan de contrôle Kubernetes pour joindre des instances à un cluster et gérer les volumes Amazon EBS. Permet également de décrire et de répertorier les ressources EC2 telles que les instances VPCs, les sous-réseaux, les groupes de sécurité et d'autres ressources réseau.
+ **`iam`**: Permet de créer un rôle lié à un service pour Elastic Load Balancing, qui est nécessaire au provisionnement dynamique du plan de contrôle Kubernetes. ELBs
+ **`kms`**: Permet de lire une clé depuis AWS KMS, qui est requise pour que le plan de contrôle Kubernetes prenne en charge le chiffrement des secrets Kubernetes stockés dans etcd.
+ **`wafv2`**et **`shield`**: Permet d'associer et de dissocier le Web ACLs et de créer/supprimer des protections AWS Shield pour les Elastic Load Balancers.
+ ** `cognito-idp` **, ** `acm` ** et ** `elasticloadbalancing` ** : accorde les autorisations nécessaires pour décrire les clients du groupe d’utilisateurs, répertorier et décrire les certificats, et décrire les groupes cibles, qui sont nécessaires au plan de contrôle Kubernetes pour gérer les Elastic Load Balancers.
La politique comprend également plusieurs vérifications de conditions afin de garantir que les autorisations ont une portée limitée au cluster EKS spécifique géré, à l’aide de la balise `eks:eks-cluster-name`.
Pour consulter la dernière version du document de politique JSON, consultez [Amazon EKSLoad BalancingPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLoadBalancingPolicy.html#AmazonEKSLoadBalancingPolicy-json) dans le AWS Managed Policy Reference Guide.
## AWS politique gérée : Amazon EKSMCPRead OnlyAccess
Vous pouvez attacher `AmazonEKSMCPReadOnlyAccess` à vos entités IAM. Cette politique fournit un accès en lecture seule aux ressources Amazon EKS et aux AWS services associés, permettant au serveur Amazon EKS Model Context Protocol (MCP) d'effectuer des opérations d'observabilité et de dépannage sans apporter de modifications à votre infrastructure.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes qui permettent aux directeurs d'effectuer les tâches suivantes :
+ **`eks`**Permet aux principaux de décrire et de répertorier les clusters EKS, les groupes de nœuds, les modules complémentaires, les entrées d'accès, les informations et d'accéder à l'API Kubernetes pour les opérations en lecture seule.
+ **`iam`**Permet aux principaux de récupérer des informations sur les rôles IAM, les politiques et leurs pièces jointes afin de comprendre les autorisations associées aux ressources EKS.
+ **`ec2`**Permet aux principaux de décrire VPCs les sous-réseaux et les tables de routage afin de comprendre la configuration réseau des clusters EKS.
+ **`sts`**Permet aux principaux de récupérer les informations d'identité de l'appelant à des fins d'authentification et d'autorisation.
+ **`logs`**Permet aux principaux de lancer des requêtes et de récupérer les résultats des requêtes à partir des CloudWatch journaux à des fins de dépannage et de surveillance.
+ **`cloudwatch`**Permet aux principaux de récupérer des données métriques pour surveiller les performances du cluster et de la charge de travail.
+ **`eks-mcp`**Permet aux principaux d'invoquer des opérations MCP et d'appeler des outils en lecture seule au sein du serveur MCP Amazon EKS.
Pour consulter la dernière version du document de politique JSON, consultez [Amazon EKSMCPRead OnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSMCPReadOnlyAccess.html) dans le AWS Managed Policy Reference Guide.
## AWS politique gérée : Amazon EKSService Policy
Vous pouvez attacher `AmazonEKSServicePolicy` à vos entités IAM. Les clusters créés avant le 16 avril 2020 nécessitaient la création d'un rôle IAM et l'ajout de cette politique. Les clusters créés à partir du 16 avril 2020 ne nécessitent pas la création d’un rôle ni l’attribution de cette politique. Lorsque vous créez un cluster à l'aide d'un principal IAM `iam:CreateServiceLinkedRole` autorisé, le rôle lié au service [AWSServiceRoleforAmazonEKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) est automatiquement créé pour vous. Le rôle lié à un service est EKSService RolePolicy associé [à la politique gérée suivante : Amazon](#security-iam-awsmanpol-amazoneksservicerolepolicy).
Cette politique permet à Amazon EKS de créer et de gérer les ressources nécessaires à l'exploitation des clusters Amazon EKS.
**Détails de l'autorisation**
Cette politique inclut les autorisations suivantes qui permettent à Amazon EKS d'effectuer les tâches suivantes.
+ ** `eks` ** : mettez à jour la version Kubernetes de votre cluster après avoir lancé une mise à jour. Cette autorisation n’est pas utilisée par Amazon EKS, mais reste dans la politique pour des raisons de compatibilité ascendante.
+ ** `ec2` ** : utilisez les interfaces réseau Elastic et d’autres ressources et balises réseau. Cela est requis par Amazon EKS pour configurer la mise en réseau qui facilite la communication entre les nœuds et le plan de contrôle Kubernetes. Lisez les informations sur les groupes de sécurité. Mettez à jour les balises sur les groupes de sécurité.
+ ** `route53` ** : associez un VPC à une zone hébergée. Cela est requis par Amazon EKS pour activer la mise en réseau de points de terminaison privés pour votre serveur d'API de cluster Kubernetes.
+ **`logs`**— Enregistrez les événements. Cela est nécessaire pour qu'Amazon EKS puisse envoyer les journaux du plan de contrôle Kubernetes à. CloudWatch
+ ** `iam` ** : créez un rôle lié à un service. Ceci est nécessaire pour qu'Amazon EKS puisse créer le rôle lié à un service [Autorisations du rôle lié à un service pour Amazon EKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) en votre nom.
Pour consulter la dernière version du document de politique JSON, consultez [Amazon EKSService Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html#AmazonEKSServicePolicy-json) dans le AWS Managed Policy Reference Guide.
## AWS politique gérée : Amazon EKSService RolePolicy
Vous ne pouvez pas associer `AmazonEKSServiceRolePolicy` à vos entités IAM. Cette politique est attachée à un rôle lié à un service qui permet à Amazon EKS d'effectuer des actions en votre nom. Pour de plus amples informations, veuillez consulter [Autorisations du rôle lié à un service pour Amazon EKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks). Lorsque vous créez un cluster à l'aide d'un principal IAM `iam:CreateServiceLinkedRole` autorisé, le rôle lié au service [AWSServiceRoleforAmazonEKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) est automatiquement créé pour vous et cette politique y est associée.
Cette politique permet au rôle lié au service d'appeler les AWS services en votre nom.
**Détails de l'autorisation**
Cette politique inclut les autorisations suivantes qui permettent à Amazon EKS d'effectuer les tâches suivantes.
+ ** `ec2` ** : créez et décrivez les interfaces réseau Elastic et les instances Amazon EC2, le groupe de sécurité du cluster et le VPC nécessaires à la création d’un cluster. Pour de plus amples informations, veuillez consulter [Voir les exigences relatives aux groupes de sécurité Amazon EKS pour les clusters](sec-group-reqs.md). Lisez les informations sur les groupes de sécurité. Mettez à jour les balises sur les groupes de sécurité. Consultez les informations relatives aux réserves de capacité à la demande. Lisez la configuration du VPC, y compris les tables de routage et le réseau, ACLs pour détecter les problèmes de configuration dans le cadre des informations sur le cluster.
+ **Mode automatique `ec2`** : résiliez les instances EC2 créées par le mode automatique EKS. Pour de plus amples informations, veuillez consulter [Automatisation de l’infrastructure du cluster avec le mode automatique EKS](automode.md).
+ ** `iam` ** : répertoriez toutes les politiques gérées associées à un rôle IAM. Cette condition est nécessaire pour permettre à Amazon EKS de répertorier et valider toutes les politiques et autorisations gérées requises pour créer un cluster.
+ **Associer un VPC à une zone hébergée** : cela est requis par Amazon EKS pour activer la mise en réseau de points de terminaison privés pour votre serveur d'API de cluster Kubernetes.
+ **Journaliser les événements** : cela est nécessaire pour qu'Amazon EKS puisse envoyer les journaux du plan de contrôle Kubernetes à. CloudWatch
+ **Put metric** : cela est nécessaire pour qu'Amazon EKS puisse envoyer les journaux du plan de contrôle Kubernetes à. CloudWatch
+ ** `eks` ** : gérez les entrées et les politiques d’accès au cluster, ce qui permet un contrôle précis des personnes autorisées à accéder aux ressources EKS et des actions qu’elles peuvent effectuer. Cela inclut l’association de politiques d’accès standard pour les opérations de calcul, de mise en réseau, d’équilibrage de charge et de stockage.
+ ** `elasticloadbalancing` ** : créez, gérez et supprimez les équilibreurs de charge et leurs composants (écouteurs, groupes cibles, certificats) associés aux clusters EKS. Affichez les attributs et l’état des équilibreurs de charge.
+ **`events`**- Créez et gérez des EventBridge règles pour surveiller les événements EC2 et AWS Health liés aux clusters EKS, afin de permettre des réponses automatisées aux modifications de l'infrastructure et aux alertes de santé.
+ ** `iam` ** : gérez les profils d’instance EC2 avec le préfixe « eks », y compris la création, la suppression et l’association de rôles, ce qui est nécessaire pour la gestion des nœuds EKS. Permet de décrire n'importe quel profil d'instance pour permettre aux utilisateurs de définir des profils d'instance personnalisés à utiliser par leurs nœuds de travail.
+ **`pricing`**`shield`****- Accédez aux informations AWS tarifaires et à l'état de protection du Shield, permettant de gérer les coûts et de bénéficier de fonctionnalités de sécurité avancées pour les ressources EKS.
+ **Nettoyage des ressources** : supprimez en toute sécurité les ressources balisées EKS, y compris les volumes, les instantanés, les modèles de lancement et les interfaces réseau, lors des opérations de nettoyage des clusters.
Pour consulter la dernière version du document de politique JSON, consultez [Amazon EKSService RolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html#AmazonEKSServiceRolePolicy-json) dans le AWS Managed Policy Reference Guide.
## AWS politique gérée : Amazon EKSVPCResource Controller
Vous pouvez associer la politique `AmazonEKSVPCResourceController` à vos identités IAM. Si vous utilisez des [groupes de sécurité pour les pods](security-groups-for-pods.md), vous devez associer cette politique à votre [rôle IAM de cluster Amazon EKS](cluster-iam-role.md) pour effectuer des actions en votre nom.
Cette politique accorde les autorisations de rôle de cluster pour gérer les interfaces réseau Elastic et les adresses IP pour les nœuds.
**Détails de l'autorisation**
Cette politique inclut les autorisations suivantes qui permettent à Amazon EKS d'effectuer les tâches suivantes :
+ ** `ec2` ** : gérez les interfaces réseau Elastic et les adresses IP pour prendre en charge les groupes de sécurité des pods et les nœuds Windows.
Pour consulter la dernière version du document de politique JSON, consultez [Amazon EKSVPCResource Controller](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSVPCResourceController.html#AmazonEKSVPCResourceController-json) dans le AWS Managed Policy Reference Guide.
## AWS politique gérée : Amazon EKSWorker NodePolicy
Vous pouvez attacher `AmazonEKSWorkerNodePolicy` à vos entités IAM. Vous devez attacher cette politique à un [rôle IAM de nœud](create-node-role.md) spécifié lorsque vous créez des nœuds Amazon EC2 qui permettent à Amazon EKS d'effectuer des actions en votre nom. Si vous créez un groupe de nœuds à l'aide de `eksctl`, il crée le rôle IAM de nœud et attache automatiquement cette politique au rôle.
Cette politique accorde aux nœuds Amazon EKS Amazon EC2 les autorisations de connexion aux clusters Amazon EKS.
**Détails de l'autorisation**
Cette politique inclut les autorisations suivantes qui permettent à Amazon EKS d'effectuer les tâches suivantes :
+ ** `ec2` ** : lisez les informations relatives au volume et au réseau de l’instance. Ceci est nécessaire pour que les nœuds Kubernetes puissent décrire des informations sur les ressources Amazon EC2 requises pour que le nœud puisse rejoindre le cluster Amazon EKS.
+ ** `eks` ** : décrivez éventuellement le cluster dans le cadre du démarrage du nœud.
+ ** `eks-auth:AssumeRoleForPodIdentity` ** : autorisez la récupération des informations d’identification pour les charges de travail EKS sur le nœud. Cela est nécessaire pour que l’identité du pod EKS fonctionne correctement.
Pour consulter la dernière version du document de politique JSON, consultez [Amazon EKSWorker NodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html#AmazonEKSWorkerNodePolicy-json) dans le AWS Managed Policy Reference Guide.
## AWS politique gérée : Amazon EKSWorker NodeMinimalPolicy
Vous pouvez associer les WorkerNodeMinimalPolicy Amazoneks à vos entités IAM. Vous pouvez associer cette politique à un rôle IAM de nœud que vous spécifiez lors de la création de nœuds Amazon EC2 qui permettent à Amazon EKS d’effectuer des actions en votre nom.
Cette politique accorde aux nœuds Amazon EKS Amazon EC2 les autorisations de connexion aux clusters Amazon EKS. Cette politique comporte moins d'autorisations que celle d'Amazon EKSWorkerNodePolicy.
**Détails de l'autorisation**
Cette politique inclut les autorisations suivantes qui permettent à Amazon EKS d'effectuer les tâches suivantes :
+ `eks-auth:AssumeRoleForPodIdentity` : permet la récupération des informations d’identification pour les charges de travail EKS sur le nœud. Cela est nécessaire pour que l’identité du pod EKS fonctionne correctement.
Pour consulter la dernière version du document de politique JSON, consultez [Amazon EKSWorker NodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodeMinimalPolicy.html#AmazonEKSWorkerNodeMinimalPolicy-json) dans le AWS Managed Policy Reference Guide.
## AWS politique gérée : AWSService RoleForAmazon EKSNodegroup
Vous ne pouvez pas associer `AWSServiceRoleForAmazonEKSNodegroup` à vos entités IAM. Cette politique est attachée à un rôle lié à un service qui permet à Amazon EKS d'effectuer des actions en votre nom. Pour de plus amples informations, veuillez consulter [Autorisations du rôle lié à un service pour Amazon EKS](using-service-linked-roles-eks-nodegroups.md#service-linked-role-permissions-eks-nodegroups).
Cette politique accorde au rôle les autorisations `AWSServiceRoleForAmazonEKSNodegroup` qui lui permettent de créer et de gérer les groupes de nœuds Amazon EC2 dans votre compte.
**Détails de l'autorisation**
Cette politique inclut les autorisations suivantes qui permettent à Amazon EKS d'effectuer les tâches suivantes :
+ ** `ec2` ** : permet de travailler avec des groupes de sécurité, des balises, des réserves de capacité et des modèles de lancement. Ceci est nécessaire pour que les groupes de nœuds gérés Amazon EKS puissent activer la configuration de l’accès à distance et décrire les réserves de capacité pouvant être utilisées dans les groupes de nœuds gérés. En outre, les groupes de nœuds gérés par Amazon EKS créent un modèle de lancement en votre nom. Cela permet de configurer le groupe Amazon EC2 Auto Scaling qui prend en charge chaque groupe de nœuds gérés.
+ ** `iam` ** : permet de créer un rôle lié à un service et de transmettre un rôle. Ceci est requis par les groupes de nœuds gérés Amazon EKS pour gérer les profils d'instance pour le rôle transmis lors de la création d'un groupe de nœuds gérés. Ce profil d'instance est utilisé par les instances Amazon EC2 lancées dans le cadre d'un groupe de nœuds gérés. Amazon EKS doit créer des rôles liés au service pour d'autres services tels que les groupes Amazon EC2 Auto Scaling. Ces autorisations sont utilisées dans la création d'un groupe de nœuds gérés.
+ ** `autoscaling` ** : permet de travailler avec des groupes Auto Scaling. Ceci est requis par les groupes de nœuds gérés par Amazon EKS pour gérer le groupe Amazon EC2 Auto Scaling qui sauvegarde chaque groupe de nœuds gérés. Il est également utilisé pour prendre en charge des fonctionnalités telles que l'expulsion des pods lorsque les nœuds sont résiliés ou recyclés lors des mises à jour des groupes de nœuds et la gestion des pools de chaleur configurés sur des groupes de nœuds gérés.
Pour consulter la dernière version du document de politique JSON, consultez [AWSServiceRoleForAmazonEKSNodegroup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRoleForAmazonEKSNodegroup.html#AWSServiceRoleForAmazonEKSNodegroup-json)le Guide de référence des politiques AWS gérées.
## AWS politique gérée : Amazon EKSDashboard ServiceRolePolicy
Vous ne pouvez pas associer `AmazonEKSDashboardServiceRolePolicy` à vos entités IAM. Cette politique est attachée à un rôle lié à un service qui permet à Amazon EKS d'effectuer des actions en votre nom. Pour de plus amples informations, veuillez consulter [Autorisations du rôle lié à un service pour Amazon EKS](using-service-linked-roles-eks-dashboard.md#service-linked-role-permissions-eks-dashboard).
Cette politique accorde au rôle les autorisations `AWSServiceRoleForAmazonEKSDashboard` qui lui permettent de créer et de gérer les groupes de nœuds Amazon EC2 dans votre compte.
**Détails de l'autorisation**
Cette politique comprend les autorisations suivantes qui permettent d’accéder à ces tâches :
+ **`organizations`**— Consultez les informations relatives à la structure et aux comptes de vos AWS Organisations. Cela inclut les autorisations permettant de répertorier les comptes de votre organisation, d’afficher les unités organisationnelles et les racines, de répertorier les administrateurs délégués, d’afficher les services qui ont accès à votre organisation et de récupérer des informations détaillées sur votre organisation et vos comptes.
Pour consulter la dernière version du document de politique JSON, consultez [Amazon EKSDashboard ServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardServiceRolePolicy.html#AmazonEKSDashboardServiceRolePolicy-json) dans le AWS Managed Policy Reference Guide.
## AWS politique gérée : Amazon EBSCSIDriver Policy
Cette `AmazonEBSCSIDriverPolicy` politique permet au pilote Amazon EBS Container Storage Interface (CSI) de créer, modifier, copier, joindre, détacher et supprimer des volumes en votre nom. Cela inclut la modification des balises sur les volumes existants et l’activation de la restauration rapide des instantanés (FSR) sur les volumes EBS. Il accorde également au pilote EBS CSI les autorisations nécessaires pour créer, verrouiller, restaurer et supprimer des instantanés, ainsi que pour répertorier vos instances, volumes et instantanés.
Pour consulter la dernière version du document de politique JSON, consultez [Amazon EBSCSIDriver ServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEBSCSIDriverPolicy.html#AmazonEBSCSIDriverPolicy-json) dans le AWS Managed Policy Reference Guide.
## AWS politique gérée : Amazon EFSCSIDriver Policy
La politique `AmazonEFSCSIDriverPolicy` permet à l'interface CSI (Amazon EFS Container Storage Interface) de créer et de supprimer des points d'accès en votre nom. Il autorise également le pilote CSI Amazon EFS à répertorier vos points d'accès, vos systèmes de fichiers, vos cibles de montage et les zones de disponibilité Amazon EC2.
Pour consulter la dernière version du document de politique JSON, consultez [Amazon EFSCSIDriver ServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEFSCSIDriverPolicy.html#AmazonEFSCSIDriverPolicy-json) dans le AWS Managed Policy Reference Guide.
## AWS politique gérée : Amazon EKSLocal OutpostClusterPolicy
Vous ne pouvez pas attacher cette politique à des entités IAM. Avant de créer un cluster local, vous devez associer cette politique à votre [rôle de cluster](cluster-iam-role.md). Les clusters Kubernetes gérés par Amazon EKS appellent d'autres AWS services en votre nom. Ils le font pour gérer les ressources que vous utilisez avec le service.
La politique `AmazonEKSLocalOutpostClusterPolicy` inclut les autorisations suivantes :
+ ** `ec2` lecture d’actions** : permet aux instances du plan de contrôle de décrire les propriétés de la zone de disponibilité, de la table de routage, de l’instance et de l’interface réseau. Autorisations requises pour que les instances Amazon EC2 puissent rejoindre le cluster en tant qu’instances du plan de contrôle.
+ ** `ssm` ** : permet à Amazon EC2 Systems Manager de se connecter à l’instance du plan de contrôle, qui est utilisée par Amazon EKS pour communiquer et gérer le cluster local dans votre compte.
+ **`logs`**— Permet aux instances de transmettre des journaux à Amazon CloudWatch.
+ **`secretsmanager`**— Permet aux instances d'obtenir et de supprimer des données de démarrage pour les instances du plan de contrôle en toute sécurité à partir de AWS Secrets Manager.
+ ** `ecr` ** : permet aux pods et aux conteneurs qui s’exécutent sur les instances du plan de contrôle d’extraire les images de conteneurs stockées dans Amazon Elastic Container Registry.
Pour consulter la dernière version du document de politique JSON, consultez [Amazon EKSLocal OutpostClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostClusterPolicy.html#AmazonEKSLocalOutpostClusterPolicy-json) dans le AWS Managed Policy Reference Guide.
## AWS politique gérée : Amazon EKSLocal OutpostServiceRolePolicy
Vous ne pouvez pas associer cette politique à vos entités IAM. Lorsque vous créez un cluster à l'aide d'un principal IAM `iam:CreateServiceLinkedRole` autorisé, Amazon EKS crée automatiquement le rôle lié au service [AWSServiceRoleforAmazonEKSLocalOutpost](using-service-linked-roles-eks-outpost.md) pour vous et y associe cette politique. Cette politique permet au rôle lié au service d'appeler des AWS services en votre nom pour les clusters locaux.
La politique `AmazonEKSLocalOutpostServiceRolePolicy` inclut les autorisations suivantes :
+ ** `ec2` ** : permet à Amazon EKS de fonctionner avec des ressources de sécurité, de réseau et autres afin de lancer et de gérer avec succès les instances du plan de contrôle dans votre compte.
+ ** `ssm`, `ssmmessages` ** : permet à Amazon EC2 Systems Manager de se connecter aux instances du plan de contrôle, qui sont utilisées par Amazon EKS pour communiquer et gérer le cluster local de votre compte.
+ ** `iam` ** : permet à Amazon EKS de gérer le profil d’instance associé aux instances du plan de contrôle.
+ **`secretsmanager`**- Permet à Amazon EKS de placer les données de démarrage des instances du plan de contrôle dans AWS Secrets Manager afin qu'elles puissent être référencées de manière sécurisée lors du démarrage des instances.
+ ** `outposts` ** : permet à Amazon EKS d’obtenir des informations Outpost à partir de votre compte afin de lancer avec succès un cluster local dans un Outpost.
Pour consulter la dernière version du document de politique JSON, consultez [Amazon EKSLocal OutpostServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostServiceRolePolicy.html#AmazonEKSLocalOutpostServiceRolePolicy-json) dans le AWS Managed Policy Reference Guide.
## Amazon EKS met à jour les politiques AWS gérées
Consultez les informations relatives aux mises à jour des politiques AWS gérées pour Amazon EKS depuis que ce service a commencé à suivre ces modifications.
Pour recevoir des notifications concernant toutes les modifications apportées aux fichiers sources de cette page de documentation spécifique, vous pouvez vous abonner à l’URL suivante à l’aide d’un lecteur RSS :
```
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/security/iam-reference/security-iam-awsmanpol.adoc.atom
```
| Modifier | Description | Date |
| --- | --- | --- |
| Autorisation ajoutée à [AWS politique gérée : Amazon EKSNetworking Policy](#security-iam-awsmanpol-AmazonEKSNetworkingPolicy). | `ec2:ModifyNetworkInterfaceAttribute`Autorisation ajoutée dans`AmazonEKSNetworkingPolicy`. Cela permet au contrôleur de mode automatique Amazon EKS de modifier les attributs de l'interface réseau liés aux instances EC2. | 3 février 2026 |
| Ajout d’autorisations à [AWS politique gérée : AWSService RoleForAmazon EKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Ajouté `autoscaling:PutWarmPool``autoscaling:DeleteWarmPool`, et `autoscaling:DescribeWarmPool` autorisations pour`AWSServiceRoleForAmazonEKSNodegroup`. Cela permet aux groupes de nœuds gérés par Amazon EKS de gérer les ressources du warm pool ASG sous-jacentes tout au long du cycle de vie des groupes de nœuds. | 17 février 2026 |
| Autorisation ajoutée à [AWS politique gérée : Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Suppression de l'exigence de préfixe « eks » dans le nom du profil d'instance cible pour l'`iam:GetInstanceProfile`autorisation dans`AmazonEKSServiceRolePolicy`. Cela permet au mode automatique d'Amazon EKS de valider et d'utiliser des profils d'instance personnalisés NodeClasses sans avoir besoin du préfixe de dénomination « eks ». | 2 février 2026 |
| Autorisations ajoutées à [Amazon EBSCSIDriver Policy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | Ajout `ec2:LockSnapshot` d'une autorisation permettant au pilote EBS CSI de verrouiller directement les instantanés EBS. | 15 janvier 2026 |
| Introduction de [AWS politique gérée : Amazon EKSMCPRead OnlyAccess](#security-iam-awsmanpol-amazoneksmcpreadonlyaccess). | Amazon EKS a introduit une nouvelle politique gérée `AmazonEKSMCPReadOnlyAccess` pour activer les outils en lecture seule sur le serveur Amazon EKS MCP à des fins d'observabilité et de résolution des problèmes. | 21 novembre 2025 |
| Autorisations ajoutées à [Amazon EBSCSIDriver Policy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | `ec2:CopyVolumes`Autorisation ajoutée permettant au pilote EBS CSI de copier directement les volumes EBS. | 17 novembre 2025 |
| Autorisation ajoutée à [AWS politique gérée : Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Ajouté `ec2:DescribeRouteTables` et `ec2:DescribeNetworkAcls` autorisations pour`AmazonEKSServiceRolePolicy`. Cela permet à Amazon EKS de détecter les problèmes de configuration liés aux tables de routage VPC et au réseau ACLs pour les nœuds hybrides dans le cadre de l'analyse du cluster. | 22 octobre 2025 |
| Autorisation ajoutée à [AWSServiceRoleForAmazonEKSConnector](using-service-linked-roles-eks-connector.md) | `ssmmessages:OpenDataChannel`Autorisation ajoutée pour `AmazonEKSConnectorServiceRolePolicy` | 15 octobre 2025 |
| Autorisation ajoutée à [AWS politique gérée : Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) | Ce rôle peut associer une nouvelle stratégie d’accès `AmazonEKSEventPolicy`. Autorisations restreintes pour `ec2:DeleteLaunchTemplate` et`ec2:TerminateInstances`. | 26 août 2025 |
| Autorisation ajoutée à [AWS politique gérée : Amazon EKSLocal OutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy) | Autorisation `ssmmessages:OpenDataChannel` ajoutée à `AmazonEKSLocalOutpostServiceRolePolicy`. | 26 juin 2025 |
| Autorisation ajoutée à [AWS politique gérée : Amazon EKSCompute Policy](#security-iam-awsmanpol-AmazonEKSComputePolicy). | Mise à jour des autorisations de ressources pour les actions `ec2:RunInstances` et `ec2:CreateFleet` afin d’inclure les réserves de capacité ` arn:aws: ec2:*:*:capacity-reservation/*`. Cela permet au mode automatique Amazon EKS de lancer des instances à l’aide des réserves de capacité à la demande EC2 de votre compte. Ajout de `iam:CreateServiceLinkedRole` pour permettre au mode automatique Amazon EKS de créer le rôle lié à un service EC2 Spot `AWSServiceRoleForEC2Spot` en votre nom. | 20 juin 2025 |
| Autorisation ajoutée à [Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Ajout de l’autorisation `ec2:DescribeCapacityReservations` pour permettre au mode automatique Amazon EKS de lancer des instances à l’aide des réserves de capacité à la demande EC2 de votre compte. | 20 juin 2025 |
| Introduction de [AWS politique gérée : Amazon EKSDashboard ConsoleReadOnly](#security-iam-awsmanpol-amazoneksdashboardconsolereadonly). | Introduction de la nouvelle politique `AmazonEKSDashboardConsoleReadOnly`. | 19 juin 2025 |
| Introduction de [AWS politique gérée : Amazon EKSDashboard ServiceRolePolicy](#security-iam-awsmanpol-AmazonEKSDashboardServiceRolePolicy). | Introduction de la nouvelle politique `AmazonEKSDashboardServiceRolePolicy`. | 21 mai 2025 |
| Autorisations ajoutées à [Amazon EKSCluster Policy](#security-iam-awsmanpol-amazoneksclusterpolicy). | Ajout de l’autorisation `ec2:DeleteNetworkInterfaces` pour permettre à Amazon EKS de supprimer les interfaces réseau Elastic qui sont laissées de côté si le VPC CNI se ferme de manière inattendue. | 16 avril 2025 |
| Autorisation ajoutée à [Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Ajout `ec2:RevokeSecurityGroupEgress` d'`ec2:AuthorizeSecurityGroupEgress`autorisations permettant aux AI/ML clients d'EKS d'ajouter des règles de sortie du groupe de sécurité au cluster EKS SG par défaut compatibles avec EFA, dans le cadre de la version 1.33 d'EKS. | 14 avril 2025 |
| Autorisations ajoutées à [Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Ajout d’une autorisation pour résilier les instances EC2 créées par le mode automatique EKS. | 28 février 2025 |
| Autorisations ajoutées à [Amazon EBSCSIDriver Policy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | Ajout d’une nouvelle déclaration autorisant le pilote CSI EBS à restaurer tous les instantanés. Cela était déjà autorisé par la politique existante, mais une nouvelle déclaration explicite est nécessaire en raison d’un changement dans la gestion de l’IAM pour `CreateVolume`. Ajout de la possibilité pour le pilote CSI EBS de modifier les balises sur les volumes existants. Le pilote EBS CSI peut modifier les balises des volumes existants via un paramètre dans Kubernetes. VolumeAttributesClasses Ajout de la possibilité pour le pilote CSI EBS d’activer la restauration rapide des instantanés (FSR) sur les volumes EBS. Le pilote CSI EBS peut activer la FSR sur les nouveaux volumes via des paramètres dans les classes de stockage Kubernetes. | 13 janvier 2025 |
| Ajout d’autorisations à [AWS politique gérée : Amazon EKSLoad BalancingPolicy](#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy). | Mise à jour d’`AmazonEKSLoadBalancingPolicy` pour permettre la liste et la description des ressources réseau et des adresses IP. | 26 décembre 2024 |
| Ajout d’autorisations à [AWS politique gérée : AWSService RoleForAmazon EKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | `AWSServiceRoleForAmazonEKSNodegroup` mis à jour pour être compatible avec les régions chinoises. | 22 novembre 2024 |
| Ajout d’autorisations à [AWS politique gérée : Amazon EKSLocal OutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) | `ec2:DescribeAvailabilityZones`Autorisation ajoutée `AmazonEKSLocalOutpostClusterPolicy` afin que le AWS Cloud Controller Manager du plan de contrôle du cluster puisse identifier la zone de disponibilité dans laquelle se trouve chaque nœud. | 21 novembre 2024 |
| Ajout d’autorisations à [AWS politique gérée : AWSService RoleForAmazon EKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Politique `AWSServiceRoleForAmazonEKSNodegroup` mise à jour pour autoriser `ec2:RebootInstances` sur les instances créées par des groupes de nœuds gérés par Amazon EKS. Restriction des autorisations `ec2:CreateTags` pour les ressources Amazon EC2. | 20 novembre 2024 |
| Ajout d’autorisations à [AWS politique gérée : Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Politique AWS gérée mise à jour par EKS`AmazonEKSServiceRolePolicy`. Ajout d’autorisations pour les stratégies d’accès EKS, la gestion des équilibreurs de charge et le nettoyage automatisé des ressources du cluster. | 16 novembre 2024 |
| Introduction de [AWS politique gérée : Amazon EKSCompute Policy](#security-iam-awsmanpol-AmazonEKSComputePolicy). | Politique AWS gérée mise à jour par EKS`AmazonEKSComputePolicy`. Autorisations de ressources mises à jour pour l’action `iam:AddRoleToInstanceProfile`. | 7 novembre 2024 |
| Introduction de [AWS politique gérée : Amazon EKSCompute Policy](#security-iam-awsmanpol-AmazonEKSComputePolicy). | AWS a présenté le`AmazonEKSComputePolicy`. | 1er novembre 2024 |
| Ajout d’autorisations à `AmazonEKSClusterPolicy` | Ajout d’une autorisation `ec2:DescribeInstanceTopology` permettant à Amazon EKS d’associer des informations de topologie au nœud sous forme d’étiquettes. | 1er novembre 2024 |
| Introduction de [AWS politique gérée : Amazon EKSBlock StoragePolicy](#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy). | AWS a présenté le`AmazonEKSBlockStoragePolicy`. | 30 octobre 2024 |
| Introduction de [AWS politique gérée : Amazon EKSLoad BalancingPolicy](#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy). | AWS a présenté le`AmazonEKSLoadBalancingPolicy`. | 30 octobre 2024 |
| Autorisations ajoutées à [Amazon EKSService RolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Des `cloudwatch:PutMetricData` autorisations ont été ajoutées pour permettre à Amazon EKS de publier des métriques sur Amazon CloudWatch. | 29 octobre 2024 |
| Introduction de [AWS politique gérée : Amazon EKSNetworking Policy](#security-iam-awsmanpol-AmazonEKSNetworkingPolicy). | AWS a présenté le`AmazonEKSNetworkingPolicy`. | 28 octobre 2024 |
| Ajout d’autorisations à `AmazonEKSServicePolicy` et `AmazonEKSServiceRolePolicy` | Ajout de `ec2:GetSecurityGroupsForVpc` et association d’autorisations de balises pour permettre à EKS de lire les informations relatives aux groupes de sécurité et de mettre à jour les balises associées. | 10 octobre 2024 |
| Présentation [d'Amazon EKSWorker NodeMinimalPolicy](#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy). | AWS a présenté le`AmazonEKSWorkerNodeMinimalPolicy`. | 3 octobre 2024 |
| Ajout d’autorisations à [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Ajout des autorisations `autoscaling:ResumeProcesses` et `autoscaling:SuspendProcesses` pour permettre à Amazon EKS de suspendre et de reprendre `AZRebalance` dans les groupes Auto Scaling gérés par Amazon EKS. | 21 août 2024 |
| Ajout d’autorisations à [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Ajout de l’autorisation `ec2:DescribeCapacityReservations` pour permettre à Amazon EKS de décrire la réserve de capacité dans le compte de l’utilisateur. Ajout de l’autorisation `autoscaling:PutScheduledUpdateGroupAction` pour permettre la configuration d’une mise à l’échelle planifiée sur les groupes de nœuds `CAPACITY_BLOCK`. | 27 juin 2024 |
| [AmazonEKS\$1CNI\$1Policy](#security-iam-awsmanpol-amazoneks-cni-policy) : mise à jour d’une politique existante | Amazon EKS a ajouté de nouvelles autorisations `ec2:DescribeSubnets` pour permettre au plug-in CNI Amazon VPC pour Kubernetes de voir le nombre d’adresses IP libres dans vos sous-réseaux Amazon VPC. Le CNI VPC peut utiliser les adresses IP libres dans chaque sous-réseau pour sélectionner les sous-réseaux disposant du plus grand nombre d’adresses IP libres à utiliser lors de la création d’une interface réseau Elastic. | 4 mars 2024 |
| [Amazon EKSWorker NodePolicy](#security-iam-awsmanpol-amazoneksworkernodepolicy) — Mise à jour d'une politique existante | Amazon EKS a ajouté de nouvelles autorisations pour permettre les identités du pod EKS. L’agent d’identité du pod Amazon EKS utilise le rôle de nœud. | 26 novembre 2023 |
| Présentation de la [EFSCSIDriverpolitique d'Amazon](#security-iam-awsmanpol-amazonefscsidriverservicerolepolicy). | AWS a présenté le`AmazonEFSCSIDriverPolicy`. | 26 juillet 2023 |
| Autorisations ajoutées à [Amazon EKSCluster Policy](#security-iam-awsmanpol-amazoneksclusterpolicy). | Ajout d'une autorisation `ec2:DescribeAvailabilityZones` permettant à Amazon EKS d'obtenir les détails des zones de disponibilité lors de la découverte automatique des sous-réseaux lors de la création d'équilibreurs de charge. | 7 février 2023 |
| Conditions de politique mises à jour dans [Amazon EBSCSIDriver Policy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | Conditions de stratégie non valides supprimées comportant des caractères génériques dans le champ clé `StringLike`. Nouvelle condition `ec2:ResourceTag/kubernetes.io/created-for/pvc/name: "*"` ajoutée à `ec2:DeleteVolume`, permettant au pilote EBS CSI de supprimer les volumes créés par le plug-in intégré à l'arborescence. | 17 novembre 2022 |
| Autorisations ajoutées à [Amazon EKSLocal OutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy). | Ajout de `ec2:DescribeVPCAttribute`, `ec2:GetConsoleOutput` et `ec2:DescribeSecret` pour permettre une meilleure validation des prérequis et un meilleur contrôle du cycle de vie géré. Également, ajout de `ec2:DescribePlacementGroups` et `"arn:aws: ec2:*:*:placement-group/*"` à `ec2:RunInstances` pour permettre le contrôle du placement des instances Amazon EC2 du plan de contrôle sur les Outposts. | 24 octobre 2022 |
| Mettez à jour les autorisations d'Amazon Elastic Container Registry dans [Amazon EKSLocal OutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy). | Déplacement de l'action `ecr:GetDownloadUrlForLayer` de toutes les sections de ressources vers une section délimitée. Ajout de la ressource ` arn:aws: ecr:*:*:repository/eks/ `. Suppression de la ressource ` arn:aws: ecr:`. Cette ressource est couverte par la ressource ` arn:aws: ecr:*:*:repository/eks/*` ajoutée. | 20 octobre 2022 |
| Autorisations ajoutées à [Amazon EKSLocal OutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy). | Ajout du référentiel Amazon Elastic Container Registry ` arn:aws: ecr:*:*:repository/kubelet-config-updater` pour que les instances du plan de contrôle du cluster puissent mettre à jour des arguments `kubelet`. | 31 août 2022 |
| Présentation [d'Amazon EKSLocal OutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy). | AWS a présenté le`AmazonEKSLocalOutpostClusterPolicy`. | 24 août 2022 |
| Présentation [d'Amazon EKSLocal OutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy). | AWS a présenté le`AmazonEKSLocalOutpostServiceRolePolicy`. | 23 août 2022 |
| Présentation de la [EBSCSIDriverpolitique d'Amazon](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | AWS a présenté le`AmazonEBSCSIDriverPolicy`. | 4 avril 2022 |
| Autorisations ajoutées à [Amazon EKSWorker NodePolicy](#security-iam-awsmanpol-amazoneksworkernodepolicy). | Ajouté `ec2:DescribeInstanceTypes` pour permettre à Amazon EKS d'être optimisé pour détecter automatiquement AMIs les propriétés au niveau de l'instance. | 21 mars 2022 |
| Ajout d’autorisations à [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Ajout d'autorisations `autoscaling:EnableMetricsCollection` permettant à Amazon EKS d'activer la collecte de métriques. | 13 décembre 2021 |
| Autorisations ajoutées à [Amazon EKSCluster Policy](#security-iam-awsmanpol-amazoneksclusterpolicy). | Ajout de `ec2:DescribeAccountAttributes`, `ec2:DescribeAddresses` et `ec2:DescribeInternetGateways` pour autoriser Amazon EKS à créer un rôle lié à un service pour un Network Load Balancer. | 17 juin 2021 |
| Amazon EKS a commencé à assurer le suivi des modifications. | Amazon EKS a commencé à suivre les modifications apportées AWS à ses politiques gérées. | 17 juin 2021 |
# Dépannage IAM
Cette rubrique traite de certaines erreurs courantes que vous pouvez rencontrer lorsque vous utilisez Amazon EKS avec IAM, ainsi que des solutions.
## AccessDeniedException
Si vous recevez un message `AccessDeniedException` lors de l'appel d'une opération d' AWS API, cela signifie que les informations d'identification [principales IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que vous utilisez ne disposent pas des autorisations requises pour effectuer cet appel.
```
An error occurred (AccessDeniedException) when calling the DescribeCluster operation:
User: arn:aws: iam::111122223333:user/user_name is not authorized to perform:
eks:DescribeCluster on resource: arn:aws: eks:region:111122223333:cluster/my-cluster
```
Dans l'exemple de message ci-précédent, l'utilisateur n'est pas autorisé à appeler l'opération d'API `DescribeCluster` Amazon EKS. Pour accorder des autorisations d'administrateur Amazon EKS à un principal IAM, consultez la rubrique [Exemples de politiques basées sur l'identité d'Amazon EKS](security-iam-id-based-policy-examples.md).
Pour plus d'informations générales sur IAM, consultez [Contrôle de l'accès à l'aide de politiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html) dans le *Guide de l'utilisateur IAM*.
## Impossible de voir **les nœuds** dans l'onglet **Calcul** ou dans l'onglet **Ressources** et vous recevez un message d'erreur dans le AWS Management Console
Vous pouvez voir un message d'erreur de la console indiquant `Your current user or role does not have access to Kubernetes objects on this EKS cluster`. Assurez-vous que l'utilisateur [principal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) AWS Management Console avec lequel vous utilisez dispose des autorisations nécessaires. Pour de plus amples informations, veuillez consulter [Autorisations requises](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
## aws-auth `ConfigMap` n'accorde pas l'accès au cluster
L’[AWS IAM Authenticator](https://github.com/kubernetes-sigs/aws-iam-authenticator) n’autorise pas de chemin dans l’ARN de rôle utilisé dans le `ConfigMap`. Par conséquent, avant de spécifier `rolearn`, supprimez le chemin d'accès. Remplacez, par exemple, ` arn:aws: iam::111122223333:role/team/developers/eks-admin ` par ` arn:aws: iam::111122223333:role/eks-admin `.
## Je ne suis pas autorisé à effectuer iam : PassRole
Si vous recevez une erreur indiquant que vous n’êtes pas autorisé à effectuer l’action `iam:PassRole`, vos politiques doivent être mises à jour pour vous permettre de transmettre un rôle à Amazon EKS.
Certains AWS services vous permettent de transmettre un rôle existant à ce service au lieu de créer un nouveau rôle de service ou un rôle lié à un service. Pour ce faire, vous devez disposer des autorisations nécessaires pour transmettre le rôle au service.
L'exemple d'erreur suivant se produit lorsqu'un utilisateur IAM nommé `marymajor` essaie d'utiliser la console pour effectuer une action dans Amazon EKS. Toutefois, l'action nécessite que le service ait des autorisations accordées par une fonction du service. Mary n'est pas autorisée à transmettre le rôle au service.
```
User: {arn-aws}iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
Dans ce cas, les politiques de Mary doivent être mises à jour pour lui permettre d’effectuer l’action `iam:PassRole`.
Si vous avez besoin d'aide, contactez votre AWS administrateur. Votre administrateur vous a fourni vos informations d’identification de connexion.
## Je souhaite autoriser des personnes extérieures à mon AWS compte à accéder à mes ressources Amazon EKS
Vous pouvez créer un rôle que les utilisateurs provenant d’autres comptes ou les personnes extérieures à votre organisation pourront utiliser pour accéder à vos ressources. Vous pouvez spécifier qui est autorisé à assumer le rôle. Pour les services qui prennent en charge les politiques basées sur les ressources ou les listes de contrôle d'accès (ACLs), vous pouvez utiliser ces politiques pour autoriser les utilisateurs à accéder à vos ressources.
Pour plus d’informations, consultez les éléments suivants :
+ Pour savoir si Amazon EKS est compatible avec ces fonctionnalités, consultez [Fonctionnement d'Amazon EKS avec IAM](security-iam-service-with-iam.md).
+ Pour savoir comment fournir un accès à vos ressources sur les AWS comptes que vous possédez, consultez la section [Fournir un accès à un utilisateur IAM sur un autre AWS compte que vous possédez](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) dans le Guide de l'*utilisateur IAM*.
+ Pour savoir comment fournir l'accès à vos ressources à des AWS comptes tiers, consultez la section [Fournir un accès aux AWS comptes détenus par des tiers](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) dans le *guide de l'utilisateur IAM*.
+ Pour savoir comment fournir un accès par le biais de la fédération d’identité, consultez [Fournir un accès à des utilisateurs authentifiés en externe (fédération d’identité)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) dans le *Guide de l’utilisateur IAM*.
+ Pour en savoir plus sur la différence entre l’utilisation des rôles et des politiques basées sur les ressources pour l’accès intercompte, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*.
## 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`
Vos conteneurs reçoivent cette erreur si votre application envoie explicitement des demandes au point de terminaison global AWS STS (`https://sts.amazonaws`) et si votre compte de service Kubernetes est configuré pour utiliser un point de terminaison régional. Vous pouvez résoudre le problème avec l'une des options suivantes :
+ Mettez à jour le code de votre application pour supprimer les appels explicites au point de terminaison global AWS STS.
+ Mettez à jour le code de votre application pour effectuer des appels explicites vers des points de terminaison régionaux tels que `https://sts.us-west-2.amazonaws.com`. Votre application doit comporter une redondance intégrée pour choisir une autre AWS région en cas de panne du service dans la AWS région. Pour plus d'informations, consultez [la section Gestion du AWS STS dans une AWS région](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html) dans le guide de l'utilisateur IAM.
+ Configurez vos comptes de service pour utiliser le point de terminaison mondial. Les clusters utilisent le point de terminaison régional par défaut. Pour de plus amples informations, veuillez consulter [Configurer le point de terminaison du service de jetons de sécurité AWS pour un compte de service](configure-sts-endpoint.md).
# Rôle IAM de cluster Amazon EKS
Un rôle IAM du cluster Amazon EKS est requis pour chaque cluster. Les clusters Kubernetes gérés par Amazon EKS utilisent ce rôle pour gérer les nœuds, tandis que [l’ancien fournisseur de cloud](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider) utilise ce rôle pour créer des équilibreurs de charge avec Elastic Load Balancing pour les services.
Avant de pouvoir créer des clusters Amazon EKS, vous devez créer un rôle IAM avec l'une des politiques IAM suivantes :
+ [EKSClusterPolitique d'Amazon](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html)
+ Une politique IAM personnalisée. Les autorisations minimales ci-dessous permettent au cluster Kubernetes de gérer les nœuds, mais n’autorisent pas l’[ancien fournisseur de cloud](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider) à créer des équilibreurs de charge avec Elastic Load Balancing. Votre politique IAM personnalisée doit disposer au moins des autorisations suivantes :
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"ForAnyValue:StringLike": {
"aws:TagKeys": "kubernetes.io/cluster/*"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeVpcs",
"ec2:DescribeDhcpOptions",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeInstanceTopology",
"kms:DescribeKey"
],
"Resource": "*"
}
]
}
```
**Note**
Avant le 3 octobre 2023, [Amazon EKSCluster Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html) était obligatoire concernant le rôle IAM de chaque cluster.
Avant le 16 avril 2020, [Amazon EKSService Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html) et [Amazon EKSCluster Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html) étaient obligatoires et le nom suggéré pour le rôle était`eksServiceRole`. Avec le rôle `AWSServiceRoleForAmazonEKS` lié au service, la [EKSServicepolitique Amazon Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html) n'est plus requise pour les clusters créés le 16 avril 2020 ou après cette date.
## Recherche d'un rôle de cluster existant
Vous pouvez utiliser la procédure suivante pour vérifier si votre compte possède déjà le rôle de cluster Amazon EKS.
1. Ouvrez la console IAM à https://console.aws.amazon.com/iam/ l'adresse.
1. Dans le volet de navigation de gauche, choisissez **Rôles**.
1. Recherchez dans la liste des rôles `eksClusterRole`. Si un rôle qui inclut `eksClusterRole` n’existe pas, consultez [Création du rôle de cluster Amazon EKS](#create-service-role) pour créer le rôle. Si un rôle qui inclut `eksClusterRole` existe, sélectionnez le rôle pour afficher les politiques attachées.
1. Choisissez **Permissions (Autorisations)**.
1. Assurez-vous que la **EKSClusterpolitique gérée par Amazon** Policy est attachée au rôle. Si la politique est attachée, votre rôle de cluster Amazon EKS est configuré correctement.
1. Sélectionnez l'onglet **Trust relationships** (Relations d'approbation), puis **Edit trust policy** (Modifier la relation d'approbation).
1. Vérifiez que la relation d'approbation contient la politique suivante. Si la relation d'approbation correspond à la politique ci-dessous, sélectionnez **Annuler**. Si la relation d’approbation ne correspond pas, copiez la politique dans la fenêtre **Modifier la politique d’approbation** et sélectionnez **Mettre à jour la politique**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
## Création du rôle de cluster Amazon EKS
Vous pouvez utiliser la AWS Management Console ou la AWS CLI pour créer le rôle de cluster.
AWS Management Console
1. Ouvrez la console IAM à https://console.aws.amazon.com/iam/ l'adresse.
1. Choisissez **Roles** (Rôles) puis **Create role** (Créer un rôle).
1. Sous **Type d'entité de confiance**, sélectionnez ** AWS service**.
1. Dans la liste déroulante **Cas d'utilisation d'autres AWS services**, sélectionnez **EKS**.
1. Sélectionnez **EKS - Cluster** pour votre cas d'utilisation, puis **Next** (Suivant).
1. Sous l'onglet **Add permissions** (Ajouter des autorisations), sélectionnez **Next** (Suivant).
1. Pour **Role name** (Nom de rôle), saisissez un nom unique pour votre rôle, par exemple, `eksClusterRole`.
1. Pour **Description**, saisissez un texte descriptif tel que `Amazon EKS - Cluster role`.
1. Choisissez **Créer un rôle**.
AWS CLI
1. Copiez le contenu suivant dans un fichier nommé *cluster-trust-policy.json*.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Créez le rôle. Vous pouvez remplacer *eksClusterRole* par n'importe quel nom que vous choisissez.
```
aws iam create-role \
--role-name eksClusterRole \
--assume-role-policy-document file://"cluster-trust-policy.json"
```
1. Attachez la politique IAM requise au rôle.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy \
--role-name eksClusterRole
```
# Rôle IAM de nœud Amazon EKS
Le `kubelet` démon du nœud Amazon EKS effectue des appels AWS APIs en votre nom. Les nœuds reçoivent l'autorisation pour ces appels d'API via un profil d'instance IAM et les politiques associées. Avant de pouvoir lancer les nœuds et les enregistrer dans un cluster, vous devez créer un rôle IAM qui sera utilisé par ces nœuds lors de leur lancement. Cette exigence s'applique aux nœuds lancés avec l'AMI optimisée Amazon EKS fournie par Amazon, ou avec tout autre nœud AMIs que vous avez l'intention d'utiliser. En outre, cette exigence s'applique à la fois aux groupes de nœuds gérés et aux nœuds autogérés.
**Note**
Vous ne pouvez pas utiliser le même rôle que celui utilisé pour créer des clusters.
Avant de créer des nœuds, vous devez créer un rôle IAM avec les autorisations suivantes :
+ Autorisations permettant `kubelet` de décrire les EC2 ressources Amazon dans le VPC, telles que prévues par la politique d'[Amazon EKSWorker NodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html). Cette politique fournit également les autorisations pour l'agent d'identité du pod Amazon EKS.
+ [Autorisations relatives `kubelet` à l'utilisation d'images de conteneurs issues d'Amazon Elastic Container Registry (Amazon ECR), telles que prévues par la politique d'Amazon. EC2 ContainerRegistryPullOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ContainerRegistryPullOnly.html) Les autorisations d'utiliser des images de conteneurs provenant d'Amazon Elastic Container Registry (Amazon ECR) sont nécessaires parce que les modules complémentaires intégrés pour la mise en réseau exécutent des pods qui utilisent des images de conteneurs provenant d'Amazon ECR.
+ (Facultatif) Autorisations permettant à l'agent d'identité du pod Amazon EKS d'utiliser l'action `eks-auth:AssumeRoleForPodIdentity` pour récupérer les informations d'identification pour les pods. Si vous n'utilisez pas [Amazon EKSWorker NodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html), vous devez fournir cette autorisation en plus des EC2 autorisations d'utilisation d'EKS Pod Identity.
+ (Facultatif) Si vous n’utilisez pas IRSA ou l’identité du pod EKS pour accorder des autorisations aux pods VPC CNI, vous devez alors attribuer les autorisations du VPC CNI au rôle de l’instance. Vous pouvez utiliser la politique [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html)gérée (si vous avez créé votre cluster avec la `IPv4` famille) ou une [IPv6 politique que vous créez](cni-iam-role.md#cni-iam-role-create-ipv6-policy) (si vous avez créé votre cluster avec la `IPv6` famille). Cependant, plutôt que d'attacher la politique à ce rôle, nous vous recommandons de l'attacher à un rôle distinct utilisé spécifiquement pour le module complémentaire Amazon VPC CNI. Pour plus d'informations sur la création d'un rôle distinct pour le module complémentaire Amazon VPC CNI, veuillez consulter [Configuration du plug-in Amazon VPC CNI pour utiliser IRSA](cni-iam-role.md).
**Note**
Les groupes de EC2 nœuds Amazon doivent avoir un rôle IAM différent de celui du profil Fargate. Pour de plus amples informations, veuillez consulter [Rôle IAM d’exécution de pod Amazon EKS](pod-execution-role.md).
## Recherche d'un rôle de nœud existant
Vous pouvez utiliser la procédure suivante pour vérifier si votre compte possède déjà le rôle de nœud Amazon EKS.
1. Ouvrez la console IAM à https://console.aws.amazon.com/iam/ l'adresse.
1. Dans le volet de navigation de gauche, choisissez **Rôles**.
1. Recherchez `eksNodeRole`, `AmazonEKSNodeRole` ou `NodeInstanceRole` dans la liste des rôles. Si aucun rôle portant l’un de ces noms n’existe, consultez la section [Création du rôle IAM de nœud Amazon EKS](#create-worker-node-role) pour créer le rôle. Si un rôle qui contient `eksNodeRole`, `AmazonEKSNodeRole` ou `NodeInstanceRole` existe, sélectionnez-le pour afficher les politiques attachées.
1. Choisissez **Autorisations**.
1. Assurez-vous que les politiques EC2 ContainerRegistryPullOnly gérées par **Amazon EKSWorker NodePolicy** **et Amazon** sont associées au rôle ou qu'une politique personnalisée est attachée avec les autorisations minimales.
**Note**
Si la politique **AmazonEKS\$1CNI\$1Policy** est attachée au rôle, nous vous recommandons de la supprimer et de l'attacher à un rôle IAM qui est plutôt mappé au compte de service `aws-node` Kubernetes. Pour de plus amples informations, veuillez consulter [Configuration du plug-in Amazon VPC CNI pour utiliser IRSA](cni-iam-role.md).
1. Sélectionnez l'onglet **Trust relationships** (Relations d'approbation), puis **Edit trust policy** (Modifier la relation d'approbation).
1. Vérifiez que la relation d'approbation contient la politique suivante. Si la relation d'approbation correspond à la politique ci-dessous, sélectionnez **Annuler**. Si la relation d’approbation ne correspond pas, copiez la politique dans la fenêtre **Modifier la politique d’approbation** et sélectionnez **Mettre à jour la politique**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Principal": {
"Service": [
"ec2.amazonaws.com"
]
}
}
]
}
```
## Création du rôle IAM de nœud Amazon EKS
Vous pouvez créer le rôle IAM du nœud à l'aide de la AWS Management Console ou de la AWS CLI.
AWS Management Console
1. Ouvrez la console IAM à https://console.aws.amazon.com/iam/ l'adresse.
1. Dans le volet de navigation de gauche, choisissez **Rôles**.
1. Sur la page **Rôles**, choisissez **Créer un rôle**.
1. Sur la page **Select trusted entity** (Sélectionner une entité de confiance), procédez comme suit :
1. Dans la section **Type d'entité fiable**, sélectionnez ** AWS service**.
1. Sous **Use case** (Cas d'utilisation), choisissez **EC2**.
1. Choisissez **Suivant**.
1. Sur la page **Ajouter des autorisations**, associez une stratégie personnalisée ou procédez comme suit :
1. Dans la zone **Filter policies** (Politiques de filtre), saisissez `AmazonEKSWorkerNodePolicy`.
1. Cochez la case située à gauche d'**Amazon EKSWorker NodePolicy** dans les résultats de recherche.
1. Sélectionnez **Clear filters** (Effacer les filtres).
1. Dans la zone **Filter policies** (Politiques de filtre), saisissez `AmazonEC2ContainerRegistryPullOnly`.
1. Cochez la case située à gauche d'**Amazon EC2 ContainerRegistryPullOnly** dans les résultats de recherche.
La politique gérée **Amazoneks\$1CNI\$1Policy** ou une politique que vous créez doit également être attachée à ce rôle ou à [IPv6 un](cni-iam-role.md#cni-iam-role-create-ipv6-policy) autre rôle mappé au compte de service Kubernetes. `aws-node` Nous vous recommandons d'attribuer la politique au rôle associé au compte de service Kubernetes au lieu de l'affecter à ce rôle. Pour de plus amples informations, veuillez consulter [Configuration du plug-in Amazon VPC CNI pour utiliser IRSA](cni-iam-role.md).
1. Choisissez **Suivant**.
1. Sur la page **Name, review, and create** (Nommer, vérifier et créer), procédez comme suit :
1. Pour **Role name** (Nom de rôle), saisissez un nom unique pour votre rôle, par exemple, `AmazonEKSNodeRole`.
1. Pour **Description**, remplacez le texte actuel par un texte descriptif tel que `Amazon EKS - Node role`.
1. Sous **Ajouter des balises (Facultatif)**, ajoutez des métadonnées au rôle en attachant les identifications sous forme de paires clé-valeur. Pour plus d'informations sur l'utilisation des balises dans IAM, consultez la rubrique [Balisage des ressources IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) dans le *Guide de l'utilisateur IAM*.
1. Choisissez **Créer un rôle**.
AWS CLI
1. Exécutez la commande ci-dessous pour créer un fichier`node-role-trust-relationship.json`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Principal": {
"Service": [
"ec2.amazonaws.com"
]
}
}
]
}
```
1. Créez le rôle IAM.
```
aws iam create-role \
--role-name AmazonEKSNodeRole \
--assume-role-policy-document file://"node-role-trust-relationship.json"
```
1. Attachez deux politiques gérées IAM requises au rôle IAM.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodePolicy \
--role-name AmazonEKSNodeRole
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryPullOnly \
--role-name AmazonEKSNodeRole
```
1. Attachez l'une des politiques IAM suivantes au rôle IAM en fonction de la famille IP avec laquelle vous avez créé votre cluster. La politique doit être attachée à ce rôle ou à un rôle associé au compte de service `aws-node` Kubernetes utilisé pour le plug-in Amazon VPC CNI pour Kubernetes. Nous vous recommandons d'attribuer la politique au rôle associé au compte de service Kubernetes. Pour attribuer la politique au rôle associé au compte de service Kubernetes, veuillez consulter [Configuration du plug-in Amazon VPC CNI pour utiliser IRSA](cni-iam-role.md).
+ IPv4
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEKS_CNI_Policy \
--role-name AmazonEKSNodeRole
```
+ IPv6
1. Copiez la politique suivante et enregistrez-la dans un fichier appelé `vpc-cni-ipv6-policy.json`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AssignIpv6Addresses",
"ec2:DescribeInstances",
"ec2:DescribeTags",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeInstanceTypes"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
]
}
]
}
```
1. Créez la politique IAM.
```
aws iam create-policy --policy-name AmazonEKS_CNI_IPv6_Policy --policy-document file://vpc-cni-ipv6-policy.json
```
1. Attachez la politique IAM au rôle IAM. Remplacez *111122223333* par votre ID de compte.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::111122223333:policy/AmazonEKS_CNI_IPv6_Policy \
--role-name AmazonEKSNodeRole
```
# Rôle IAM du cluster du mode automatique Amazon EKS
Un rôle IAM du cluster Amazon EKS est requis pour chaque cluster. Les clusters Kubernetes gérés par Amazon EKS utilisent ce rôle pour automatiser les tâches courantes liées au stockage, à la mise en réseau et à l’autoscaling de la puissance de calcul.
Avant de pouvoir créer des clusters Amazon EKS, vous devez créer un rôle IAM avec les politiques nécessaires pour le mode automatique EKS. Vous pouvez soit joindre les stratégies gérées par AWS IAM suggérées, soit créer des politiques personnalisées avec des autorisations équivalentes.
+ [EKSComputePolitique d'Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [AmazonEKSBlockStoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [AmazonEKSLoadBalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [EKSNetworkingPolitique d'Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [EKSClusterPolitique d'Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
## Recherche d'un rôle de cluster existant
Vous pouvez utiliser la procédure suivante pour vérifier si votre compte possède déjà le rôle de cluster Amazon EKS.
1. Ouvrez la console IAM à https://console.aws.amazon.com/iam/ l'adresse.
1. Dans le volet de navigation de gauche, choisissez **Rôles**.
1. Recherchez dans la liste des rôles `AmazonEKSAutoClusterRole`. Si aucun rôle contenant `AmazonEKSAutoClusterRole` n’existe, consultez les instructions dans la section suivante pour créer le rôle. Si un rôle qui inclut `AmazonEKSAutoClusterRole` existe, sélectionnez le rôle pour afficher les politiques attachées.
1. Choisissez **Permissions (Autorisations)**.
1. Assurez-vous que la **EKSClusterpolitique gérée par Amazon** Policy est attachée au rôle. Si la politique est attachée, votre rôle de cluster Amazon EKS est configuré correctement.
1. Sélectionnez l'onglet **Trust relationships** (Relations d'approbation), puis **Edit trust policy** (Modifier la relation d'approbation).
1. Vérifiez que la relation d'approbation contient la politique suivante. Si la relation d'approbation correspond à la politique ci-dessous, sélectionnez **Annuler**. Si la relation d’approbation ne correspond pas, copiez la politique dans la fenêtre **Modifier la politique d’approbation** et sélectionnez **Mettre à jour la politique**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
**Note**
AWS ne nécessite pas le nom `AmazonEKSAutoClusterRole` de ce rôle.
## Création du rôle de cluster Amazon EKS
Vous pouvez utiliser la AWS Management Console ou la AWS CLI pour créer le rôle de cluster.
### AWS Management Console
1. Ouvrez la console IAM à https://console.aws.amazon.com/iam/ l'adresse.
1. Choisissez **Roles** (Rôles) puis **Create role** (Créer un rôle).
1. Sous **Type d'entité de confiance**, sélectionnez ** AWS service**.
1. Dans la liste déroulante **Cas d'utilisation d'autres AWS services**, sélectionnez **EKS**.
1. Sélectionnez **EKS - Cluster** pour votre cas d'utilisation, puis **Next** (Suivant).
1. Dans l’onglet **Ajouter des autorisations**, sélectionnez les politiques, puis cliquez sur **Suivant**.
+ [EKSComputePolitique d'Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [AmazonEKSBlockStoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [AmazonEKSLoadBalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [EKSNetworkingPolitique d'Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [EKSClusterPolitique d'Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
1. Pour **Role name** (Nom de rôle), saisissez un nom unique pour votre rôle, par exemple, `AmazonEKSAutoClusterRole`.
1. Pour **Description**, saisissez un texte descriptif tel que `Amazon EKS - Cluster role`.
1. Choisissez **Créer un rôle**.
### AWS CLI
1. Copiez le contenu suivant dans un fichier nommé *cluster-trust-policy.json*.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
1. Créez le rôle. Vous pouvez remplacer *AmazonEKSAutoClusterRole* par n'importe quel nom que vous choisissez.
```
aws iam create-role \
--role-name AmazonEKSAutoClusterRole \
--assume-role-policy-document file://"cluster-trust-policy.json"
```
1. Attachez les politiques IAM requises au rôle :
**EKSClusterPolitique d'Amazon** :
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy
```
**EKSComputePolitique d'Amazon** :
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSComputePolicy
```
**Amazon EKSBlock StoragePolicy** :
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSBlockStoragePolicy
```
**Amazon EKSLoad BalancingPolicy** :
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSLoadBalancingPolicy
```
**EKSNetworkingPolitique d'Amazon** :
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSNetworkingPolicy
```
# Rôle IAM de nœud du mode automatique Amazon EKS
**Note**
Vous ne pouvez pas utiliser le même rôle que celui utilisé pour créer des clusters.
Avant de créer des nœuds, vous devez créer un rôle IAM incluant les politiques suivantes ou des autorisations équivalentes :
+ [AmazonEKSWorkerNodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
## Recherche d'un rôle de nœud existant
Vous pouvez utiliser la procédure suivante pour vérifier si votre compte possède déjà le rôle de nœud Amazon EKS.
1. Ouvrez la console IAM à https://console.aws.amazon.com/iam/ l'adresse.
1. Dans le volet de navigation de gauche, choisissez **Rôles**.
1. Recherchez dans la liste des rôles `AmazonEKSAutoNodeRole`. Si aucun rôle portant l’un de ces noms n’existe, consultez les instructions de la section suivante pour le créer. Si un rôle qui contient `AmazonEKSAutoNodeRole` existe, sélectionnez le rôle pour afficher les stratégies attachées.
1. Choisissez **Autorisations**.
1. Assurez-vous que les politiques requises ci-dessus sont bien attachées, ou utilisez des politiques personnalisées équivalentes.
1. Sélectionnez l'onglet **Trust relationships** (Relations d'approbation), puis **Edit trust policy** (Modifier la relation d'approbation).
1. Vérifiez que la relation d'approbation contient la politique suivante. Si la relation d'approbation correspond à la politique ci-dessous, sélectionnez **Annuler**. Si la relation d’approbation ne correspond pas, copiez la politique dans la fenêtre **Modifier la politique d’approbation** et sélectionnez **Mettre à jour la politique**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
## Création du rôle IAM de nœud Amazon EKS
Vous pouvez créer le rôle IAM du nœud à l'aide de la AWS Management Console ou de la AWS CLI.
### AWS Management Console
1. Ouvrez la console IAM à https://console.aws.amazon.com/iam/ l'adresse.
1. Dans le volet de navigation de gauche, choisissez **Rôles**.
1. Sur la page **Rôles**, choisissez **Créer un rôle**.
1. Sur la page **Select trusted entity** (Sélectionner une entité de confiance), procédez comme suit :
1. Dans la section **Type d'entité fiable**, sélectionnez ** AWS service**.
1. Sous **Use case** (Cas d'utilisation), choisissez **EC2**.
1. Choisissez **Suivant**.
1. Sur la page **Ajouter des autorisations**, attachez les politiques suivantes :
+ [AmazonEKSWorkerNodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
1. Sur la page **Name, review, and create** (Nommer, vérifier et créer), procédez comme suit :
1. Pour **Role name** (Nom de rôle), saisissez un nom unique pour votre rôle, par exemple, `AmazonEKSAutoNodeRole`.
1. Pour **Description**, remplacez le texte actuel par un texte descriptif tel que `Amazon EKS - Node role`.
1. Sous **Ajouter des balises (Facultatif)**, ajoutez des métadonnées au rôle en attachant les identifications sous forme de paires clé-valeur. Pour plus d'informations sur l'utilisation des balises dans IAM, consultez la rubrique [Balisage des ressources IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) dans le *Guide de l'utilisateur IAM*.
1. Choisissez **Créer un rôle**.
### AWS CLI
**Création du rôle IAM du nœud**
Utilisez le fichier **node-trust-policy.json** de l'étape précédente pour définir les entités qui peuvent assumer le rôle. Exécutez la commande suivante pour créer le rôle IAM du nœud :
```
aws iam create-role \
--role-name AmazonEKSAutoNodeRole \
--assume-role-policy-document file://node-trust-policy.json
```
**Enregistrement de l’ARN du rôle**
Après la création du rôle, extrayez et enregistrez l’ARN du rôle IAM du nœud. Cet ARN sera nécessaire dans les étapes suivantes. Utilisez la commande suivante pour extraire l’ARN :
```
aws iam get-role --role-name AmazonEKSAutoNodeRole --query "Role.Arn" --output text
```
**Association des politiques requises**
Associez les politiques AWS gérées suivantes au rôle Node IAM pour fournir les autorisations nécessaires :
Pour joindre Amazon, procédez comme suit EKSWorker NodeMinimalPolicy :
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodeMinimalPolicy
```
Pour joindre Amazon, procédez comme suit EC2 ContainerRegistryPullOnly :
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
```
# Fonctionnalité Amazon EKS : rôle IAM
Les fonctionnalités EKS nécessitent la configuration d'un rôle IAM de fonctionnalité (ou rôle de capacité). Les fonctionnalités utilisent ce rôle pour effectuer des actions sur les AWS services et pour accéder aux ressources Kubernetes de votre cluster via des entrées d'accès créées automatiquement.
Avant de pouvoir spécifier un rôle de capacité lors de la création d'une fonctionnalité, vous devez créer le rôle IAM avec la politique de confiance et les autorisations appropriées pour le type de capacité. Une fois ce rôle IAM créé, il peut être réutilisé pour n'importe quel nombre de ressources de capacité.
## Exigences relatives aux rôles de capacité
Le rôle de capacité doit répondre aux exigences suivantes :
+ Le rôle doit figurer dans le même AWS compte que le cluster et la ressource de capacité
+ Le rôle doit avoir une politique de confiance qui permet au service des capacités EKS d'assumer le rôle
+ Le rôle doit disposer d'autorisations adaptées au type de fonctionnalité et aux exigences du cas d'utilisation (voir[Autorisations par type de capacité](#capability-permissions))
## Politique de confiance pour les rôles liés aux capacités
Tous les rôles de capacité doivent inclure la politique de confiance suivante :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
Cette politique de confiance permet à EKS de :
+ Assumez le rôle d'effectuer des opérations AWS d'API
+ Étiquetez les sessions à des fins d'audit et de suivi
## Autorisations par type de capacité
Les autorisations IAM requises dépendent de la fonctionnalité que vous utilisez et de votre modèle de déploiement.
**Note**
Pour les déploiements de production utilisant des sélecteurs de rôles IAM avec ACK, ou lorsque vous utilisez Kro ou Argo CD sans intégration de AWS services, le rôle de capacité peut ne nécessiter aucune autorisation IAM au-delà de la politique de confiance.
**kro (Kube Resource Orchestrator)**
Aucune autorisation IAM n'est requise. Vous pouvez créer un rôle de capacité sans politique attachée. Kro n'a besoin que des autorisations RBAC de Kubernetes pour créer et gérer les ressources Kubernetes.
** AWS Contrôleurs pour Kubernetes (ACK)**
ACK prend en charge deux modèles d'autorisation :
+ **Configuration simple (développement/test)** : ajoutez des autorisations AWS de service directement au rôle de capacité. Cela fonctionne bien pour la mise en route, les déploiements à compte unique ou lorsque tous les utilisateurs ont besoin des mêmes autorisations.
+ **Bonnes pratiques de production** : utilisez les sélecteurs de rôles IAM pour implémenter l'accès avec le moindre privilège. Avec cette approche, le rôle de capacité n'a besoin que d'une `sts:AssumeRole` autorisation pour assumer des rôles spécifiques au service. Vous n'ajoutez pas d'autorisations de AWS service (comme S3 ou RDS) au rôle de capacité lui-même : ces autorisations sont accordées à des rôles IAM individuels mappés à des espaces de noms spécifiques.
Les sélecteurs de rôles IAM permettent de :
+ Isolation des autorisations au niveau de l'espace de noms
+ Gestion des ressources entre comptes
+ Rôles IAM spécifiques à l'équipe
+ Modèle de sécurité fondé sur le moindre privilège
Exemple de politique de rôle de capacité pour l'approche du sélecteur de rôle IAM :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::111122223333:role/ACK-S3-Role",
"arn:aws:iam::111122223333:role/ACK-RDS-Role",
"arn:aws:iam::444455556666:role/ACKCrossAccountRole"
]
}
]
}
```
Pour une configuration détaillée des autorisations ACK, y compris les sélecteurs de rôle IAM, voir. [Configurer les autorisations ACK](ack-permissions.md)
**Argo CD**
Aucune autorisation IAM n'est requise par défaut. Des autorisations facultatives peuvent être nécessaires pour :
+ ** AWS Secrets Manager** : si vous utilisez Secrets Manager pour stocker les informations d'identification du référentiel Git
+ ** AWS CodeConnections**: en cas d'utilisation CodeConnections pour l'authentification du dépôt Git
Exemple de politique pour Secrets Manager et CodeConnections :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret"
],
"Resource": "arn:aws:secretsmanager:region:account-id:secret:argocd/*"
},
{
"Effect": "Allow",
"Action": [
"codeconnections:UseConnection",
"codeconnections:GetConnection"
],
"Resource": "arn:aws:codeconnections:region:account-id:connection/*"
}
]
}
```
Pour connaître les exigences détaillées en matière d'autorisation sur Argo CD, voir[Considérations relatives à Argo CD](argocd-considerations.md).
## Vérifier la présence d'un rôle de capacité existant
Vous pouvez utiliser la procédure suivante pour vérifier si votre compte possède déjà un rôle IAM de fonctionnalité adapté à votre cas d'utilisation.
1. Ouvrez la console IAM à https://console.aws.amazon.com/iam/ l'adresse.
1. Dans le volet de navigation de gauche, choisissez **Rôles**.
1. Recherchez dans la liste des rôles le nom de votre rôle de capacité (par exemple, `ACKCapabilityRole` ou`ArgoCDCapabilityRole`).
1. Si un rôle existe, sélectionnez-le pour afficher les politiques et la relation de confiance associées.
1. Sélectionnez l'onglet **Trust relationships** (Relations d'approbation), puis **Edit trust policy** (Modifier la relation d'approbation).
1. Vérifiez que la relation de confiance correspond à la [politique de confiance des capacités](#capability-trust-policy). Si elle ne correspond pas, mettez à jour la politique de confiance.
1. Choisissez **Autorisations** et vérifiez que le rôle dispose des autorisations appropriées pour votre type de fonctionnalité et votre cas d'utilisation.
## Création d'un rôle IAM de capacité
Vous pouvez utiliser la AWS Management Console ou la AWS CLI pour créer un rôle de capacité.
** AWS Management Console **
1. Ouvrez la console IAM à https://console.aws.amazon.com/iam/ l'adresse.
1. Choisissez **Roles** (Rôles) puis **Create role** (Créer un rôle).
1. Sous **Type d'entité fiable**, sélectionnez **Politique de confiance personnalisée**.
1. Copiez et collez la [politique de confiance des capacités](#capability-trust-policy) dans l'éditeur de politique de confiance.
1. Choisissez **Suivant**.
1. Dans l'onglet **Ajouter des autorisations**, sélectionnez ou créez des politiques adaptées à votre type de fonctionnalité (voir[Autorisations par type de capacité](#capability-permissions)). Pour Kro, vous pouvez ignorer cette étape.
1. Choisissez **Suivant**.
1. Dans **Nom du rôle**, entrez un nom unique pour votre rôle, tel que `ACKCapabilityRole``ArgoCDCapabilityRole`, ou`kroCapabilityRole`.
1. Pour **Description**, saisissez un texte descriptif tel que `Amazon EKS - ACK capability role`.
1. Choisissez **Créer un rôle**.
** AWS CLI**
1. Copiez la [politique de confiance en matière de capacités](#capability-trust-policy) dans un fichier nommé`capability-trust-policy.json`.
1. Créez le rôle. `ACKCapabilityRole`Remplacez-le par le nom de rôle de votre choix.
```
aws iam create-role \
--role-name ACKCapabilityRole \
--assume-role-policy-document file://capability-trust-policy.json
```
1. Associez les politiques IAM requises au rôle. Pour ACK, associez des politiques aux AWS services que vous souhaitez gérer. Pour Argo CD, joignez des politiques pour Secrets Manager ou CodeConnections si nécessaire. Pour Kro, vous pouvez ignorer cette étape.
Exemple pour ACK avec autorisations S3 :
```
aws iam put-role-policy \
--role-name ACKCapabilityRole \
--policy-name S3Management \
--policy-document file://s3-policy.json
```
## Résolution des problèmes liés aux rôles liés aux capacités
**La création de capacités échoue avec un « rôle IAM non valide »**
Vérifiez que :
+ Le rôle existe dans le même compte que le cluster
+ La politique de confiance correspond à la [politique de confiance des capacités](#capability-trust-policy)
+ Vous êtes `iam:PassRole` autorisé à jouer le rôle
**La fonctionnalité affiche les erreurs d'autorisation**
Vérifiez que :
+ Le rôle dispose des autorisations IAM nécessaires pour le type de fonctionnalité
+ L'entrée d'accès existe sur le cluster pour le rôle
+ Des autorisations Kubernetes supplémentaires sont configurées si nécessaire (voir) [Autorisations Kubernetes supplémentaires](capabilities-security.md#additional-kubernetes-permissions)
**Les ressources ACK échouent avec des erreurs « autorisation refusée »**
Vérifiez que :
+ Le rôle dispose des autorisations IAM nécessaires pour votre cas d'utilisation
+ Pour les contrôleurs ACK qui font référence à des secrets, assurez-vous d'avoir associé la politique d'entrée d'`AmazonEKSSecretReaderPolicy`accès aux espaces de noms appropriés.
Pour plus de conseils de résolution des problèmes, consultez[Considérations relatives à la sécurité relatives aux fonctionnalités EKS](capabilities-security.md).