Sécurité de l'infrastructure dans Amazon EKS - Amazon EKS

Aidez à améliorer cette page

Pour contribuer à ce guide de l’utilisateur, cliquez sur le lien Modifier cette page sur GitHub qui se trouve dans le volet droit de chaque page.

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. 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 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 (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.

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, 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.

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 (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.

Vous pouvez mettre en œuvre les politiques réseau Kubernetes avec Amazon VPC CNI ou des outils tiers tels que Project Calico. 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. Project Calico tiers est un projet open source tierce. Pour plus d'informations, consultez la documentation Project Calico.