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 tous.
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 sur 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 les API appels AWS publiés pour accéder à Amazon EKS via le réseau. Les clients doivent prendre en charge les éléments suivants :
-
Sécurité de la couche de transport (TLS). Nous avons besoin de la TLS version 1.2 et recommandons la TLS version 1.3.
-
Des suites de chiffrement parfaitement confidentielles (PFS) telles que (Ephemeral Diffie-Hellman) ou DHE 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 identifiant de clé d'accès et d'une clé d'accès secrète associés à un IAM principal. 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 EKS cluster Amazon, vous spécifiez les VPC sous-réseaux que votre cluster doit utiliser. Amazon a EKS besoin de sous-réseaux dans au moins deux zones de disponibilité. Nous recommandons d'utiliser VPC des sous-réseaux publics et privés afin de créer des équilibreurs de charge publics dans les sous-réseaux publics qui équilibrent la charge du trafic avec l'Podsexécution sur les nœuds situés dans des sous-réseaux privés. Kubernetes
Pour plus d'informations sur VPC les considérations, voirAfficher les exigences EKS réseau d'Amazon pour VPC et les sous-réseaux.
Si vous créez vos groupes de nœuds VPC et de nœuds à l'aide des AWS CloudFormation modèles fournis dans la Commencez 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 Afficher les exigences relatives aux groupes EKS de sécurité Amazon pour les clusters.
Lorsque vous créez un nouveau cluster, Amazon EKS crée un point de terminaison pour le Kubernetes API serveur géré que vous utilisez pour communiquer avec votre cluster (à l'aide d'outils de Kubernetes gestion tels quekubectl). Par défaut, ce point de terminaison API du serveur est public sur Internet, et l'accès au API serveur est sécurisé à l'aide d'une combinaison de AWS Identity and Access Management (IAM) et d'un contrôle d'accès basé sur les Kubernetes rôles
Vous pouvez activer l'accès privé au Kubernetes API serveur afin que toutes les communications entre vos nœuds et le API serveur restent dans le vôtreVPC. Vous pouvez limiter les adresses IP qui peuvent accéder à votre API serveur depuis Internet ou désactiver complètement l'accès Internet au API serveur.
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 des politiques Kubernetes réseau avec Amazon VPC CNI ou des outils tiers tels que Project Calico
