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.

Utilisation des politiques réseau avec le mode automatique EKS

Vue d’ensemble

À mesure que les clients font évoluer leurs environnements applicatifs à l'aide d'EKS, l'isolation du trafic réseau devient de plus en plus fondamentale pour empêcher tout accès non autorisé aux ressources à l'intérieur et à l'extérieur du cluster. Cela est particulièrement important dans un environnement mutualisé où plusieurs charges de travail indépendantes s'exécutent côte à côte dans le cluster. Les politiques réseau Kubernetes vous permettent d'améliorer la sécurité du réseau pour vos charges de travail Kubernetes et leur intégration aux points de terminaison externes du cluster. Le mode automatique EKS prend en charge différents types de politiques réseau.

Isolation des couches 3 et 4

Les politiques réseau standard de Kubernetes fonctionnent aux couches 3 et 4 du modèle de réseau OSI et vous permettent de contrôler le flux de trafic au niveau de l'adresse IP ou du port au sein de votre cluster Amazon EKS.

Cas d’utilisation

DNS-based mise en application

Les clients déploient généralement des charges de travail dans EKS qui font partie d'un environnement distribué plus large, dont certaines doivent communiquer avec des systèmes et des services extérieurs au cluster (trafic en direction du nord). Ces systèmes et services peuvent se trouver dans le AWS cloud ou en dehors du AWS cloud. Les politiques basées sur le système de noms de domaine (DNS) vous permettent de renforcer votre posture de sécurité en adoptant une approche plus stable et prévisible pour empêcher l'accès non autorisé des pods aux ressources ou aux points de terminaison externes au cluster. Ce mécanisme élimine le besoin de suivre et d'autoriser manuellement des adresses IP spécifiques à la liste. En sécurisant les ressources à l'aide d'une DNS-based approche, vous bénéficiez également d'une plus grande flexibilité pour mettre à jour l'infrastructure externe sans avoir à assouplir votre dispositif de sécurité ou à modifier les politiques réseau en cas de modification des serveurs et des hôtes en amont. Vous pouvez filtrer le trafic sortant vers des points de terminaison externes à l'aide d'un nom de domaine complet (FQDN) ou d'un modèle correspondant à un nom de domaine DNS. Cela vous donne la flexibilité supplémentaire d'étendre l'accès à plusieurs sous-domaines associés à un point de terminaison externe au cluster particulier.

Cas d’utilisation

Règles d'administration (ou à l'échelle du cluster)

Dans certains cas, tels que les scénarios multi-locataires, les clients peuvent être tenus d'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. Ces types de politiques vous permettent d'étendre le champ d'application de vos règles de filtrage réseau appliquées aux couches 3, 4 et lors de l'utilisation de règles DNS.

Cas d’utilisation

Prise en main

Conditions préalables

Étape 1 : activer le contrôleur de politiques réseau

Pour utiliser les politiques réseau avec le mode automatique EKS, vous devez d'abord activer le Network Policy Controller en appliquant a ConfigMap à votre cluster.

Étape 2 : Création et test de politiques réseau

Votre cluster du mode automatique EKS est maintenant configuré pour prendre en charge les politiques réseau Kubernetes. Vous pouvez tester cette configuration à l’aide de Démonstration des politiques réseau pour Amazon EKS.

Étape 3 : Ajuster la configuration de l'agent de politique réseau dans la classe de nœuds (facultatif)

Vous pouvez éventuellement créer une nouvelle classe de nœuds pour modifier le comportement par défaut de l'agent de politique réseau sur les nœuds ou activer la journalisation des événements de politique réseau. Pour cela, procédez comme suit :

Fonctionnement

DNS-based politique de réseau

Utilisation de la politique réseau d'applications

Il ApplicationNetworkPolicy combine les fonctionnalités des politiques réseau standard de Kubernetes avec le filtrage basé sur le DNS au niveau de l'espace de noms à l'aide d'une seule définition de ressource personnalisée (CRD). Par conséquent, ApplicationNetworkPolicy ils peuvent être utilisés pour :

Exemple

Dans votre cluster EKS Auto Mode, vous avez une charge de travail qui doit communiquer avec une application sur site qui se trouve derrière un équilibreur de charge avec un nom DNS. Vous pouvez y parvenir en utilisant la politique réseau suivante :

apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
  name: my-onprem-app-egress
  namespace: galaxy
spec:
  podSelector:
    matchLabels:
      role: backend
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock: { cidr: 10.100.0.10/32 }
    ports:
    - protocol: TCP
      port: 53
    - protocol: UDP
      port: 53
  - to:
    - domainNames:
      - "myapp.mydomain.com"
    ports:
    - protocol: TCP
      port: 8080

Au niveau du réseau Kubernetes, cela permettrait de sortir de tous les pods de l'espace de noms « galaxy » étiqueté role: backend pour se connecter au nom de domaine myapp.mydomain.com sur le port TCP 8080 et à CoreDNS sur le port 53. En outre, vous devez configurer la connectivité réseau pour le trafic sortant de votre VPC vers le centre de données de votre entreprise.

Déterminer l'adresse IP CoreDNS

Pour que votre application puisse résoudre le DNS, elle doit être autorisée à communiquer avec CoreDNS, qui s'exécute localement sur chaque instance EKS Auto Mode. L'adresse IP CoreDNS est dérivée de la plage d'adresses CIDR de service configurée pour le cluster et reste fixe pendant toute la durée de vie du cluster. Vous pouvez donc le déterminer une seule fois et le référencer directement dans vos politiques réseau.

Politique réseau d'administration (ou de cluster)

Utilisation de la politique de réseau de clusters

Lorsque vous utilisez unClusterNetworkPolicy, les politiques du niveau Admin sont évaluées en premier et ne peuvent pas être remplacées. Lorsque les politiques du niveau Admin ont été évaluées, les politiques standard étendues à l'espace de noms sont utilisées pour exécuter les règles de segmentation du réseau appliquées. Cela peut être accompli en utilisant l'une ApplicationNetworkPolicy ou l'autre des optionsNetworkPolicy. Enfin, les règles du niveau de base qui définissent les restrictions réseau par défaut pour les charges de travail des clusters seront appliquées. Ces règles de niveau de base peuvent être remplacées par les politiques délimitées par les espaces de noms si nécessaire.

Exemple

Votre cluster contient une application que vous souhaitez isoler des charges de travail des autres locataires. Vous pouvez bloquer explicitement le trafic de cluster provenant d'autres espaces de noms afin d'empêcher l'accès réseau à l'espace de noms sensible de la charge de travail.

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

Considérations

Comprendre l'ordre d'évaluation des politiques

Les fonctionnalités de politique réseau prises en charge par EKS sont évaluées dans un ordre spécifique afin de garantir une gestion du trafic prévisible et sécurisée. Il est donc important de comprendre le flux d'évaluation afin de concevoir une posture de sécurité réseau efficace pour votre environnement.

Appliquer le principe du moindre privilège

Utilisation de DNS-based politiques dans EKS

Validation de vos politiques DNS

Interaction avec le pare-feu DNS Amazon Route 53

Les politiques d'administration et de réseau EKS sont d'abord évaluées au niveau du pod lorsque le trafic est initié. Si une politique réseau EKS autorise la sortie vers un domaine spécifique, le pod exécute ensuite une requête DNS qui atteint le résolveur Route 53. À ce stade, les règles du pare-feu DNS Route 53 sont évaluées. Si le pare-feu DNS bloque la requête de domaine, la résolution DNS échoue et la connexion ne peut pas être établie, même si la politique réseau EKS l'autorisait. Cela crée des couches de sécurité complémentaires : les politiques DNS-based réseau EKS fournissent un contrôle de sortie au niveau du pod pour les exigences d'accès spécifiques aux applications et les limites de sécurité multi-locataires, tandis que le pare-feu DNS fournit une VPC-wide protection contre les domaines malveillants connus et applique les listes de blocage à l'échelle de l'organisation.