Présentation de Prise en main Fonctionnement Considé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.

Utilisation des politiques réseau avec le mode automatique EKS

Présentation de

À mesure que les clients adaptent 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é dans lequel 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 le niveau de sécurité du réseau pour vos charges de travail Kubernetes, ainsi que leur intégration avec les points de terminaison externes au 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 s'appliquent 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

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.

Application basée sur le DNS

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 être hébergés dans le AWS cloud ou AWS totalement externes. 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 tout accès non autorisé des pods aux ressources ou points de terminaison externes au cluster. Ce mécanisme élimine le besoin de suivre manuellement et d'autoriser la création de listes d'adresses IP spécifiques. En sécurisant les ressources grâce à une approche basée sur le DNS, vous bénéficiez également d'une plus grande flexibilité pour mettre à jour l'infrastructure externe sans avoir à assouplir votre posture de sécurité ou à modifier les politiques réseau en cas de modifications apportées aux serveurs et 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 de correspondance pour 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

Utilisez une approche basée sur le DNS pour filtrer l'accès depuis un environnement Kubernetes vers des points de terminaison externes au cluster.
Accès sécurisé aux AWS services dans un environnement mutualisé.
Gérez l'accès au réseau, des modules aux charges de travail sur site dans vos environnements de cloud hybride.

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

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

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 à l'étendue du cluster de manière plus efficace sur le plan opérationnel.

Prise en main

Conditions préalables

Cluster Amazon EKS avec le mode automatique EKS activé
kubectl configuré pour se connecter à votre cluster

É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 un ConfigMap à votre cluster.

Créez un fichier nommé enable-network-policy.yaml avec le contenu suivant:


apiVersion: v1
kind: ConfigMap
metadata:
  name: amazon-vpc-cni
  namespace: kube-system
data:
  enable-network-policy-controller: "true"

Appliquez le ConfigMap à votre cluster :
```
kubectl apply -f enable-network-policy.yaml
```

Étape 2 : créer et tester des 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 stratégie réseau sur les nœuds ou activer la journalisation des événements de politique réseau. Pour cela, procédez comme suit :

Créez ou modifiez un fichier YAML de classe de nœud (par exemple, nodeclass-network-policy.yaml) avec le contenu suivant :


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: network-policy-config
spec:
  # Optional: Changes default network policy behavior
  networkPolicy: DefaultAllow
  # Optional: Enables logging for network policy events
  networkPolicyEventLogs: Enabled
  # Include other Node Class configurations as needed

Appliquez la configuration de la classe de nœuds à votre cluster :
```
kubectl apply -f nodeclass-network-policy.yaml
```
Vérifiez que la classe de nœuds a été créée :
```
kubectl get nodeclass network-policy-config
```
Mettez à jour votre groupe de nœuds pour utiliser cette classe de nœuds. Pour de plus amples informations, veuillez consulter Create a Node Pool for EKS Auto Mode.

Fonctionnement

Politique réseau basée sur le DNS

Illustration du flux de travail lorsqu'une politique basée sur le DNS est appliquée dans EKS Auto

L'équipe de la plateforme applique une politique basée sur le DNS au cluster EKS.
Le Network Policy Controller est chargé de surveiller la création des politiques au sein du cluster, puis de réconcilier les points de terminaison des politiques. Dans ce cas d'utilisation, le contrôleur de stratégie réseau demande à l'agent du nœud de filtrer les demandes DNS en fonction des domaines autorisés dans la politique créée. Les noms de domaine sont autorisés à l'aide du nom de domaine complet ou d'un nom de domaine correspondant à un modèle défini dans la configuration des ressources Kubernetes.
La charge de travail A tente de résoudre l'adresse IP d'un point de terminaison externe au cluster. La demande DNS passe d'abord par un proxy qui filtre ces demandes en fonction de la liste d'autorisation appliquée par le biais de la politique réseau.
Une fois que la demande DNS passe par la liste d'autorisation du filtre DNS, elle est transmise par proxy à CoreDNS,
CoreDNS envoie à son tour la demande au résolveur DNS externe (Amazon Route 53 Resolver) pour obtenir la liste des adresses IP sous-jacentes au nom de domaine.
Les données résolues IPs avec TTL sont renvoyées dans la réponse à la demande DNS. Ils IPs sont ensuite écrits dans une carte eBPF qui est utilisée à l'étape suivante pour l'application de la couche IP.
Les sondes eBPF connectées à l'interface Pod veth filtreront ensuite le trafic sortant de la charge de travail A vers le point de terminaison externe au cluster en fonction des règles en place. Cela garantit que les pods ne peuvent envoyer du trafic externe au cluster que vers les domaines autorisés IPs répertoriés. Leur validité IPs est basée sur le TTL extrait du résolveur DNS externe (Amazon Route 53 Resolver).

Utilisation de la politique du 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 en utilisant une seule définition de ressource personnalisée (CRD). Par conséquent, ApplicationNetworkPolicy ils peuvent être utilisés pour :

Définition des restrictions au niveau des couches 3 et 4 de la pile réseau à l'aide de blocs IP et de numéros de port.
Définir des règles qui s'appliquent à la couche 7 de la pile réseau et vous permettre de filtrer le trafic en fonction de FQDNs.

Remarque importante : les règles basées sur le DNS définies à l'aide du ne ApplicationNetworkPolicy s'appliquent qu'aux charges de travail exécutées dans des instances lancées en mode EKS Auto. EC2

Exemple

Dans votre cluster EKS Auto Mode, vous avez une charge de travail qui doit communiquer avec une application sur site située derrière un équilibreur de charge portant un nom DNS. Vous pouvez y parvenir en appliquant 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:
    - 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é avec role: backend pour se connecter au nom de domaine myapp.mydomain.com sur le port TCP 8080. 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.

Illustration de la charge de travail dans EKS Auto communiquant avec les applications sur site

Politique réseau de l'administrateur (ou du cluster)

illustration de l'ordre d'évaluation des politiques réseau dans EKS

Utilisation de la politique réseau du cluster

Lorsque vous utilisez unClusterNetworkPolicy, les politiques du niveau administrateur sont évaluées en premier et ne peuvent pas être remplacées. Lorsque les politiques de niveau administrateur ont été évaluées, les politiques délimitées par espace de noms standard sont utilisées pour exécuter les règles de segmentation du réseau appliquées. Cela peut être accompli en utilisant l'un ApplicationNetworkPolicy ou l'autreNetworkPolicy. Enfin, les règles du niveau de référence qui définissent les restrictions réseau par défaut pour les charges de travail des clusters seront appliquées. Ces règles du niveau de base peuvent être remplacées par les politiques délimitées de l'espace 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 du cluster en provenance d'autres espaces de noms afin d'empêcher l'accès réseau à l'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

Considérations

Comprendre l'ordre d'évaluation des politiques

Les fonctionnalités de politique réseau prises en charge dans 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.

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.
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 traditionnelles ApplicationNetworkPolicy et 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 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.
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).
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é.

Appliquer le principe du moindre privilège

Commencez par des politiques restrictives et ajoutez progressivement des autorisations selon les besoins : commencez par mettre en œuvre des deny-by-default politiques au niveau du cluster, puis ajoutez progressivement des règles d'autorisation au fur et à mesure que vous validez les exigences de connectivité légitimes. Cette approche oblige les équipes à justifier explicitement chaque connexion externe, créant ainsi un environnement plus sécurisé et plus contrôlable.
Auditez régulièrement et supprimez les règles de politique non utilisées : les politiques réseau peuvent s'accumuler au fil du temps à mesure que les applications évoluent, laissant derrière elles des règles obsolètes qui étendent inutilement votre surface d'attaque. Mettez en œuvre un processus de révision régulier pour identifier et supprimer les règles de politique qui ne sont plus nécessaires, afin de garantir que votre posture de sécurité reste stricte et maintenable.
Utilisez des noms de domaine spécifiques plutôt que des modèles généraux lorsque cela est possible. Si les modèles génériques sont pratiques, ils *.amazonaws.com permettent également d'accéder à un large éventail de services. Dans la mesure du possible, spécifiez des noms de domaine exacts, par exemple s3.us-west-2.amazonaws.com pour limiter l'accès aux seuls services spécifiques dont vos applications ont besoin, réduisant ainsi le risque de déplacement latéral si une charge de travail est compromise.

Utilisation de politiques basées sur le DNS dans EKS

Les règles basées sur le DNS définies à l'aide du ApplicationNetworkPolicy ne s'appliquent qu'aux charges de travail exécutées dans des instances lancées en mode EKS Auto. EC2 Si vous utilisez un cluster en mode mixte (composé à la fois de nœuds de travail EKS Auto et de nœuds de travail autres qu'EKS Auto), vos règles basées sur le DNS ne sont efficaces que dans les nœuds de travail en mode EKS Auto (instances EC2 gérées).

Validation de vos politiques DNS

Utilisez des clusters intermédiaires qui reflètent la topologie du réseau de production pour les tests - Votre environnement intermédiaire doit reproduire l'architecture réseau, les dépendances externes et les modèles de connectivité de production afin de garantir des tests de politiques précis. Cela inclut les configurations VPC correspondantes, le comportement de résolution DNS et l'accès aux mêmes services externes dont vos charges de travail de production ont besoin.
Mettez en œuvre des tests automatisés pour les chemins réseau critiques - Créez des tests automatisés qui valident la connectivité aux services externes essentiels dans le cadre de votre CI/CD pipeline. Ces tests doivent vérifier que les flux de trafic légitimes sont autorisés tandis que les connexions non autorisées sont bloquées, afin de valider en permanence que vos politiques réseau maintiennent le bon niveau de sécurité au fur et à mesure de l'évolution de votre infrastructure.
Surveillez le comportement des applications après les modifications des politiques : après avoir déployé des politiques réseau nouvelles ou modifiées en production, surveillez de près les journaux des applications, les taux d'erreur et les indicateurs de performance pour identifier rapidement les problèmes de connectivité. Établissez des procédures d'annulation claires afin de pouvoir annuler rapidement les modifications de politique si elles entraînent un comportement inattendu des applications ou des interruptions de service.

Interaction avec le pare-feu DNS Amazon Route 53

Les politiques d'administration et de réseau d'EKS sont d'abord évaluées au niveau du module lorsque le trafic est initié. Si une politique réseau EKS autorise la sortie vers un domaine spécifique, le pod exécute alors 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'autorise. Cela crée des couches de sécurité complémentaires : les politiques réseau basées sur le DNS d'EKS fournissent un contrôle des sorties au niveau du pod pour répondre aux exigences d'accès spécifiques aux applications et aux limites de sécurité mutualisées, tandis que le pare-feu DNS fournit une protection à l'échelle du VPC contre les domaines malveillants connus et applique des listes de blocage à l'échelle de l'organisation.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Exécuter les modules complémentaires critiques

Baliser les sous-réseaux