Limitation du trafic des pods à l’aide des politiques réseau Kubernetes - Amazon EKS
Présentation de Politique réseau standardPolitique réseau de l'administrateur (ou du cluster)Remarques importantesConsidérations

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

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

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

  3. 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).

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