**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.
# 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"
}
}
}
]
}
```