Aidez à améliorer cette page
Vous souhaitez contribuer à ce guide de l'utilisateur ? Faites défiler cette page vers le bas et sélectionnez Modifier cette page sur GitHub. Vos contributions aideront à améliorer notre guide de l'utilisateur pour tout le monde.
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é de l'infrastructure dans Amazon EKS
En tant que service géré, Amazon Elastic Kubernetes Service est protégé par la sécurité du réseau mondial. AWS Pour plus d'informations sur les services AWS de sécurité et sur la manière dont AWS l'infrastructure est protégée, consultez la section Sécurité du AWS cloud
Vous utilisez des appels d'API AWS publiés 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 AWS Security Token Service (AWS STS) pour générer des informations d'identification de sécurité temporaires et 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 la charge du 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 Exigences et considérations Amazon EKS requises pour le VPC et les sous-réseaux.
Si vous créez votre VPC et vos groupes de nœuds à l'aide des AWS CloudFormation modèles fournis dans la Démarrer avec Amazon EKS procédure pas à pas, votre plan de contrôle et vos groupes de sécurité de nœuds sont configurés selon nos paramètres recommandés.
Pour plus d'informations sur les considérations des groupes de sécurité, consultez Considérations et exigences relatives aux groupes de sécurité Amazon EKS.
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 tels que 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 AWS Identity and Access Management (IAM) et de contrôle d'accès basé sur les Kubernetes rôles
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 implémenter des stratégies réseau Kubernetes avec Amazon VPC CNI ou des outils tiers tels que Projet Calico
