**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. # 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 pod-to-pod trafic dans le cluster. Ces politiques réseau s'appliquent 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 afin de garantir que seules les applications associées puissent communiquer entre elles. + Isolez les locataires au niveau de l'espace de noms à l'aide de politiques visant à appliquer la séparation des réseaux. ### Exemple Dans la politique ci-dessous, le trafic sortant des pods d'*applications Web* dans l'espace de noms *Sun* est restreint. ``` 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 modules dont l'étiquette figure `role: webapp` dans l'espace de `sun` noms. + Trafic autorisé : pods dont l'étiquette figure `role: frontend` dans l'espace de `moon` noms du port TCP `8080` + Trafic autorisé : Pods portant le label role : frontend dans l'espace de `stars` noms du port TCP `8080` + Trafic bloqué : tout autre trafic sortant provenant `webapp` des pods est implicitement refusé ## Politique réseau de l'administrateur (ou du 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 seule stratégie 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 sur 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 explicitement bloquer le trafic du cluster en provenance 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 plugin 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. Avec les groupes de sécurité pour 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 les politiques réseau du plug-in Amazon VPC CNI pour Kubernetes à votre cluster à l'aide du plug-in Amazon VPC CNI pour Kubernetes, vous pouvez appliquer les politiques aux nœuds Amazon Linux uniquement. 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’à une seule famille d’adresses IP, soit `IPv4`, soit `IPv6`, mais pas aux deux en même temps. Dans un cluster `IPv4`, le plug-in VPC CNI attribue des adresses `IPv4` aux pods et applique les politiques `IPv4` correspondantes. Dans un cluster `IPv6`, le plug-in VPC CNI attribue des adresses `IPv6` aux pods et applique les politiques `IPv6` correspondantes. 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** + Les politiques réseau s’appliquent uniquement aux pods faisant partie d’un déploiement. Les pods autonomes qui n’ont pas de `metadata.ownerReferences` définies ne peuvent pas se voir appliquer de politique réseau. + 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. Des sélecteurs tels que `namespaceSelector` Resolve to a un ou plusieurs CIDRs. 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 les autres politiques. 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. + **Refuser l'action (priorité la plus élevée)** : lorsqu'une politique d'administration associée à une action de refus correspond au trafic, ce trafic est immédiatement bloqué, quelles que soient les autres politiques. Aucune autre ClusterNetworkPolicy NetworkPolicy règle n'est traitée. 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 d'autorisation 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 politique n'est effectuée. Ces politiques peuvent accorder l'accès à plusieurs espaces de noms en fonction de sélecteurs d'étiquettes, offrant ainsi un contrôle centralisé des charges de travail pouvant accéder à des ressources spécifiques. + **Action de transfert** : les actions de transfert prévues dans les politiques du niveau administrateur 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 de niveau administrateur restantes 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 d'application. Par exemple, vous pouvez utiliser les règles Pass pour déléguer la gestion du trafic intra-espace à 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 à Deny ou Allow, ou si une action Pass correspond, les NetworkPolicy ressources délimitées par un 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 d'application. Les politiques étendues à l'espace de noms 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 approuvé par les politiques d'administration. 1. **Politiques d'administration du niveau de référence** : si aucune politique d'administration ou limitée à un 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élimitées 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é de 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 deny-by-default comportement garantit que seules les connexions explicitement autorisées sont autorisées, garantissant ainsi un niveau de sécurité élevé. **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' EC2 IMDS, veillez à vérifier les politiques réseau susceptibles de bloquer l'accès à l' EC2 IMDS. Vous devrez peut-être ajouter une politique réseau pour autoriser l'accès à l' EC2 IMDS. Pour plus d'informations, consultez la section [Métadonnées de l'instance et données utilisateur](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) dans le guide de EC2 l'utilisateur Amazon. Les pods qui utilisent des *rôles IAM pour les comptes de service* ou *EKS Pod Identity* n'accèdent pas à EC2 IMDS. + 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 fonction de `IPv4` sortie de connecter les IPv6 pods à des `IPv4` points de terminaison tels que ceux situés en dehors du cluster. La fonction de `IPv4` sortie fonctionne en créant une interface réseau supplémentaire avec une adresse de boucle locale. IPv4 + 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.