**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 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. # Limitation du trafic des pods à l’aide des politiques réseau Kubernetes ## Présentation de Par défaut, Kubernetes n’impose aucune restriction concernant les adresses IP, les ports ou les connexions entre les pods d’un même cluster, ni entre vos pods et des ressources situées dans d’autres réseaux. Vous pouvez utiliser une *politique réseau* Kubernetes pour limiter le trafic réseau vers et depuis vos pods. Pour plus d’informations, consultez [Politiques réseau](https://kubernetes.io/docs/concepts/services-networking/network-policies/) dans la documentation Kubernetes. ## Politique réseau standard Vous pouvez utiliser la norme `NetworkPolicy` pour segmenter le trafic de pod à pod dans le cluster. Ces politiques réseau fonctionnent aux couches 3 et 4 du modèle de réseau OSI, ce qui vous permet de contrôler le flux de trafic au niveau de l'adresse IP ou du port au sein de votre cluster Amazon EKS. Les politiques réseau standard sont limitées au niveau de l'espace de noms. ### Cas d’utilisation + Segmentez le trafic réseau entre les charges de travail pour vous assurer que seules les applications associées peuvent communiquer entre elles. + Isolez les locataires au niveau de l'espace de noms à l'aide de politiques visant à renforcer la séparation du réseau. ### Exemple Dans la politique ci-dessous, le trafic sortant des * pods de l'*application Web dans l'*espace de noms * Sun est limité. ``` apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: webapp-egress-policy namespace: sun spec: podSelector: matchLabels: role: webapp policyTypes: - Egress egress: - to: - namespaceSelector: matchLabels: name: moon podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 8080 - to: - namespaceSelector: matchLabels: name: stars podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 8080 ``` La politique s'applique aux pods dont l'étiquette figure `role: webapp` dans l'`sun`espace de noms. + Trafic autorisé : pods dont l'étiquette figure `role: frontend` dans l'`moon`espace de noms sur le port TCP `8080` + Trafic autorisé : pods dont l'étiquette figure `role: frontend` dans l'`stars`espace de noms sur le port TCP `8080` + Trafic bloqué : tout autre trafic sortant des `webapp` pods est implicitement refusé ## Politique réseau d'administration (ou de cluster) ![Illustration de l'ordre d'évaluation des politiques réseau dans EKS](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/evaluation-order.png) Vous pouvez utiliser le `ClusterNetworkPolicy` pour appliquer une norme de sécurité réseau qui s'applique à l'ensemble du cluster. Au lieu de définir et de gérer de manière répétitive une politique distincte pour chaque espace de noms, vous pouvez utiliser une politique unique pour gérer de manière centralisée les contrôles d'accès au réseau pour les différentes charges de travail du cluster, quel que soit leur espace de noms. ### Cas d’utilisation + Gérez de manière centralisée les contrôles d'accès au réseau pour toutes les charges de travail (ou un sous-ensemble de celles-ci) de votre cluster EKS. + Définissez une posture de sécurité réseau par défaut pour l'ensemble du cluster. + Étendez les normes de sécurité organisationnelles au périmètre du cluster de manière plus efficace sur le plan opérationnel. ### Exemple Dans la politique ci-dessous, vous pouvez bloquer explicitement le trafic de cluster provenant d'autres espaces de noms afin d'empêcher l'accès réseau à un espace de noms de charge de travail sensible. ``` apiVersion: networking.k8s.aws/v1alpha1 kind: ClusterNetworkPolicy metadata: name: protect-sensitive-workload spec: tier: Admin priority: 10 subject: namespaces: matchLabels: kubernetes.io/metadata.name: earth ingress: - action: Deny from: - namespaces: matchLabels: {} # Match all namespaces. name: select-all-deny-all ``` ## Remarques importantes Les politiques réseau du plug-in Amazon VPC CNI pour Kubernetes sont prises en charge dans les configurations répertoriées ci-dessous. + Version 1.21.0 (ou ultérieure) du plug-in Amazon VPC CNI pour les politiques réseau standard et d'administration. + Cluster configuré pour les adresses `IPv4` ou `IPv6`. + Vous pouvez utiliser les politiques réseau avec des [groupes de sécurité pour les pods](security-groups-for-pods.md). Grâce aux stratégies réseau, vous pouvez contrôler toutes les communications au sein du cluster. Grâce aux groupes de sécurité pour les Pods, vous pouvez contrôler l'accès aux AWS services depuis les applications d'un Pod. + Vous pouvez utiliser les stratégies réseau avec *mise en réseau personnalisée* et *délégation de préfixes*. ## Considérations **Architecture** + Lorsque vous appliquez des politiques réseau du plug-in Amazon VPC CNI pour Kubernetes à votre cluster, ces politiques peuvent être appliquées uniquement aux nœuds Linux Amazon EC2. Il n’est pas possible d’appliquer ces politiques aux nœuds Fargate ni aux nœuds Windows. + Les politiques réseau ne s'appliquent qu'à l'une `IPv4` ou l'autre `IPv6` des adresses, mais pas aux deux. Dans un `IPv4` cluster, le VPC CNI attribue une `IPv4` adresse aux pods et applique des politiques. `IPv4` Dans un `IPv6` cluster, le VPC CNI attribue une `IPv6` adresse aux pods et applique des politiques. `IPv6` Toute règle de politique réseau `IPv4` appliquée à un cluster `IPv6` est ignorée. Toute règle de politique réseau `IPv6` appliquée à un cluster `IPv4` est ignorée. **Politiques réseau** + Amazon EKS optimise l'application des politiques réseau pour les pods dont un `metadata.ownerReferences` champ est défini. Cela inclut les pods gérés par des contrôleurs tels que Deployments, StatefulSets, DaemonSets, Jobs et CronJobs. Les pods autonomes créés directement sans contrôleur ne sont pas `metadata.ownerReferences` définis, et l'application de la politique réseau peut ne pas fonctionner de manière fiable pour ces pods. + Il est possible d’appliquer plusieurs politiques réseau à un même pod. Lorsque plusieurs politiques ciblent le même pod, toutes les politiques sont appliquées simultanément. + Le nombre maximal de combinaisons de ports et de protocoles pour une même plage d’adresses IP (CIDR) est de 24, toutes politiques réseau confondues. Les sélecteurs tels que `namespaceSelector` se traduisent par une ou plusieurs plages CIDR. Si plusieurs sélecteurs aboutissent à la même plage CIDR ou si une même plage CIDR directe est spécifiée plusieurs fois, dans une ou plusieurs politiques réseau, chacune de ces occurrences compte dans cette limite. + Pour tous les services Kubernetes, le port du service doit être identique au port du conteneur. Si vous utilisez des ports nommés, vous devez employer le même nom dans la spécification du service. **Politiques du réseau d'administration ** 1. **Politiques du niveau administrateur (évaluées en premier) ** : Toutes les politiques du niveau administrateur ClusterNetworkPolicies sont évaluées avant toute autre politique. Au niveau Administrateur, les politiques sont traitées par ordre de priorité (le numéro de priorité le plus bas en premier). Le type d'action détermine ce qui se passe ensuite. + **Action de refus (priorité la plus élevée) ** : lorsqu'une politique d'administration avec une action Refuser correspond au trafic, ce trafic est immédiatement bloqué, quelles que soient les autres politiques. Aucune autre étape ClusterNetworkPolicy ou NetworkPolicy les règles ne sont traitées. Cela garantit que les contrôles de sécurité à l'échelle de l'organisation ne peuvent pas être remplacés par des politiques au niveau de l'espace de noms. + **Autoriser l'action ** : une fois les règles de refus évaluées, les politiques d'administration comportant des actions Autoriser sont traitées par ordre de priorité (le numéro de priorité le plus bas en premier). Lorsqu'une action Autoriser correspond, le trafic est accepté et aucune autre évaluation de la politique n'a lieu. Ces politiques peuvent accorder l'accès à plusieurs espaces de noms en fonction de sélecteurs d'étiquettes, fournissant ainsi un contrôle centralisé sur les charges de travail qui peuvent accéder à des ressources spécifiques. + **Action de réussite ** : les actions de réussite prévues dans les politiques du niveau d'administration délèguent la prise de décision aux niveaux inférieurs. Lorsque le trafic correspond à une règle Pass, l'évaluation ignore toutes les règles restantes du niveau Administrateur pour ce trafic et passe directement au NetworkPolicy niveau. Cela permet aux administrateurs de déléguer explicitement le contrôle de certains modèles de trafic aux équipes chargées de l'application. Par exemple, vous pouvez utiliser les règles Pass pour déléguer la gestion du trafic interne à des administrateurs d'espaces de noms tout en maintenant des contrôles stricts sur l'accès externe. 1. **Niveau de politique réseau ** : si aucune politique de niveau administrateur ne correspond à Refuser ou à Autoriser, ou si une action Pass a été sélectionnée, les NetworkPolicy ressources limitées à l'espace de noms sont ensuite évaluées. Ces politiques fournissent un contrôle précis au sein des espaces de noms individuels et sont gérées par les équipes chargées de l'application. Namespace-scoped les politiques ne peuvent être que plus restrictives que les politiques d'administration. Ils ne peuvent pas annuler la décision de refus d'une politique d'administration, mais ils peuvent restreindre davantage le trafic autorisé ou transmis par les politiques d'administration. 1. **Politiques d'administration du niveau de référence ** : si aucune politique relative à l'administration ou à l'espace de noms ne correspond au trafic, le niveau de référence est évalué. ClusterNetworkPolicies Ils fournissent des postures de sécurité par défaut qui peuvent être remplacées par des politiques définies par des espaces de noms, permettant aux administrateurs de définir des valeurs par défaut à l'échelle de l'organisation tout en donnant aux équipes la flexibilité nécessaire pour les personnaliser selon les besoins. Les politiques de base sont évaluées par ordre de priorité (le numéro de priorité le plus bas en premier). 1. **Refus par défaut (si aucune politique ne correspond) ** : ce comportement de refus par défaut garantit que seules les connexions explicitement autorisées sont autorisées, tout en maintenant une solide posture de sécurité. **Migration** + Si votre cluster utilise actuellement une solution tierce pour gérer les politiques réseau Kubernetes, vous pouvez réutiliser ces mêmes politiques avec le plug-in Amazon VPC CNI pour Kubernetes. Cependant, vous devez supprimer la solution existante afin d’éviter qu’elle ne gère les mêmes politiques en parallèle. **Avertissement** Il est recommandé, après avoir supprimé la solution de politique réseau, de remplacer tous les nœuds sur lesquels cette solution était appliquée. Cette mesure permet d’éviter que des règles de trafic résiduelles laissées par un pod de la solution, notamment si celui-ci s’arrête brusquement, ne restent actives sur les nœuds. **Installation** + La fonctionnalité de stratégie réseau crée et nécessite une définition de ressource personnalisée (CRD) de `PolicyEndpoint` appelée `policyendpoints.networking.k8s.aws`. Les objets du `PolicyEndpoint` de la ressource personnalisée sont gérés par Amazon EKS. Vous ne devez ni modifier ni supprimer ces ressources. + Si vous exécutez des pods qui utilisent les informations d'identification IAM du rôle d'instance ou si vous vous connectez à l'IMDS EC2, veillez à vérifier les stratégies réseau susceptibles de bloquer l'accès à l'IMDS EC2. Vous devrez peut-être ajouter une stratégie réseau pour autoriser l'accès à l'IMDS EC2. Pour plus d'informations, consultez [Métadonnées d'instance et données utilisateur](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) dans le Guide de l'utilisateur Amazon EC2. Les pods qui utilisent des *rôles IAM pour les comptes de service* ou l’*identité du pod EKS* n’accèdent pas au service IMDS EC2. + Le plug-in Amazon VPC CNI pour Kubernetes n’applique pas les politiques réseau aux interfaces réseau supplémentaires pour chaque pod, mais uniquement à l’interface principale de chaque pod (`eth0`). Cela concerne les architectures suivantes : + `IPv6` pods dont la variable `ENABLE_V4_EGRESS` est définie sur `true`. Cette variable permet à la fonctionnalité de sortie `IPv4` de connecter les pods IPv6 à des points de terminaison `IPv4`, comme ceux situés en dehors du cluster. La fonctionnalité de sortie `IPv4` fonctionne en créant une interface réseau supplémentaire avec une adresse IPv4 de boucle locale. + Lorsque vous utilisez des plugins réseau chaînés tels que Multus. Comme ces plug-ins ajoutent des interfaces réseau à chaque pod, les politiques réseau ne sont pas appliquées aux plug-ins réseau chaînés.