Get best of the week

Comprendre les stratégies réseau avec Calico



Calico Network Plugin fournit une large gamme de politiques réseau avec une syntaxe unifiée pour protéger les hôtes sur le matériel, les machines virtuelles et les pods. Ces stratégies peuvent être appliquées dans l'espace de noms ou être des stratégies de réseau global applicables au point de terminaison hôte (pour protéger les applications s'exécutant directement sur l'hôte - le serveur ou la machine virtuelle peut être l'hôte directement) ou pour charger le point de terminaison de la charge de travail(pour protéger les applications s'exécutant dans des conteneurs ou des machines virtuelles hébergées). Les politiques de Calico vous permettent d'appliquer des mesures de sécurité à différents points du chemin du package à l'aide de paramètres tels que preDNAT, untracked et applyOnForward. Comprendre comment ces options fonctionnent peut aider à améliorer la sécurité et les performances du système dans son ensemble. Cet article explique l'essence de ces paramètres de stratégie Calico (preDNAT, non-annulé et applyOnForward) appliqués aux points de terminaison hôte, en mettant l'accent sur ce qui se passe dans les chemins de traitement des paquets (chaînes iptabels).

Cet article suppose que vous comprenez le fonctionnement des stratégies de réseau Kubernetes et Calico. Sinon, nous vous recommandons d'essayer le didacticiel de base sur la stratégie réseau et le didacticiel sur la protection de l'hôte à l' aide de Calico avant de lire cet article. Nous nous attendons également à ce que vous ayez une compréhension de base d' iptables sous Linux. Politique du réseau mondial de

Calicovous permet d'appliquer un ensemble de règles d'accès aux étiquettes (aux groupes d'hôtes et aux charges de travail / pods). Ceci est très utile si vous utilisez ensemble des systèmes hétérogènes - des machines virtuelles, un système directement sur le matériel ou l'infrastructure kubernetes. De plus, vous pouvez protéger votre cluster (nœuds) à l'aide d'un ensemble de stratégies déclaratives et appliquer des stratégies réseau au trafic entrant (par exemple, via le service NodePorts ou des adresses IP externes).

À un niveau fondamental, lorsque Calico connecte un pod à un réseau (voir schéma ci-dessous), il le connecte à un hôte à l'aide d'une interface Ethernet virtuelle (veth). Le trafic envoyé par le pod arrive sur l'hôte à partir de cette interface virtuelle et est traité comme s'il provenait d'une interface réseau physique. Par défaut, Calico appelle ces interfaces caliXXX. Puisque le trafic passe par l'interface virtuelle, il passe par iptables, comme si le pod était à la distance d'un bond. Par conséquent, lorsque le trafic provient / provient du pod, il est transmis du point de vue de l'hôte.

Sur le nœud Kubernetes où Calico est exécuté, vous pouvez mapper l'interface virtuelle (veth) à la charge de travail comme suit. Dans l'exemple ci-dessous, vous pouvez voir que veth # 10 (calic1cbf1ca0f8) est connecté à cnx-manager- * dans l'espace de noms calico-monitoring.

[centos@ip-172-31-31-46 K8S]$ sudo ip a
...
10: calic1cbf1ca0f8@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 5
    inet6 fe80::ecee:eeff:feee:eeee/64 scope link
       valid_lft forever preferred_lft forever
...

[centos@ip-172-31-31-46 K8S]$ calicoctl get wep --all-namespaces
...
calico-monitoring cnx-manager-8f778bd66-lz45m                            ip-172-31-31-46.ec2.internal 192.168.103.134/32
calic1cbf1ca0f8
...



Étant donné que Calico crée une interface veth pour chaque charge de travail, comment applique-t-il les stratégies? Pour ce faire, Calico crée des hooks dans différentes chaînes du chemin de traitement des packages à l'aide d'iptables.

Le diagramme ci-dessous montre les chaînes impliquées dans le traitement des paquets dans iptables (ou le sous-système netfilter). Lorsqu'un paquet arrive via une interface réseau, il passe d'abord par la chaîne PREROUTING. Ensuite, une décision de routage est prise, et sur cette base, le paquet passe par INPUT (dirigé vers les processus hôtes) ou FORWARD (dirigé vers le pod ou un autre nœud sur le réseau). À partir du processus local, le paquet passe par la chaîne de SORTIE, puis POSTROUTING avant de l'envoyer sur le câble.

Notez que pod est également un objet externe (connecté à veth) en termes de gestion des iptables. Résumer:

  • Le trafic retransmis (nat, acheminé vers / depuis le pod) passe par les chaînes PREROUTING - FORWARD - POSTROUTING.
  • Le trafic vers le processus hôte local passe par la chaîne PREROUTING - INPUT.
  • Le trafic provenant du processus hôte local passe par la chaîne OUTPUT - POSTROUTING.



Calico fournit des options de stratégie pour appliquer des stratégies à toutes les chaînes. Dans cet esprit, examinons les différents paramètres de stratégie disponibles dans Calico. Les numéros de la liste d'options ci-dessous correspondent aux numéros du schéma ci-dessus.

  1. Stratégie de point de terminaison de charge de travail (pod)
  2. Stratégie de point de terminaison hôte
  3. Option ApplyOnForward
  4. Politique PreDNAT
  5. Politique non suivie

Commençons par examiner comment les stratégies s'appliquent aux points de terminaison de charge de travail (pods Kubernetes ou OpenStack VMs), puis examinons les options de stratégie pour les points de terminaison hôte.

Points de terminaison de charge de travail


Stratégie de point de terminaison de charge de travail (1)


Il s'agit d'une option pour protéger vos pods kubernetes. Calico prend en charge le travail avec Kubernetes NetworkPolicy, mais il fournit également des politiques supplémentaires - Calico NetworkPolicy et GlobalNetworkPolicy. Calico crée une chaîne pour chaque pod (charge de travail) et accroche les chaînes INPUT et OUTPUT pour la charge de travail à la table de filtrage de la chaîne FORWARD.

Points de terminaison hôte


Stratégie de point de terminaison hôte (2)


En plus de CNI (interface de réseau de conteneurs), les politiques Calico offrent la possibilité de protéger directement l'hôte. Dans Calico, vous pouvez créer un point de terminaison hôte en spécifiant une combinaison de l'interface hôte et, si nécessaire, des numéros de port. L'application des politiques pour cette entité est réalisée en utilisant la table de filtrage dans les chaînes INPUT et OUTPUT. Comme le montre le diagramme, (2) ils sont appliqués aux processus locaux sur le nœud / hôte. Autrement dit, si vous avez créé une stratégie qui s'applique au point de terminaison hôte, cela n'affectera pas le trafic allant vers / depuis vos pods. Mais il fournit une interface / syntaxe unique pour bloquer le trafic pour votre hôte et vos pods à l'aide des politiques Calico. Cela simplifie considérablement le processus de gestion des politiques pour un réseau hétérogène. La configuration de stratégies de point de terminaison hôte pour améliorer la protection du cluster est un autre cas d'utilisation important.

Politique ApplyOnForward (3)


L'option ApplyOnForward est disponible dans la stratégie de réseau mondial Calico pour permettre aux stratégies de s'appliquer à tout le trafic passant par le point de terminaison de l'hôte, y compris le trafic qui sera transmis par l'hôte. Ce trafic comprend l'envoi vers un module local ou n'importe où ailleurs sur le réseau. Calico nécessite que ce paramètre soit activé pour les stratégies qui utilisent PreDNAT et non suivies, voir les sections suivantes. De plus, ApplyOnForward peut être utilisé pour suivre le trafic hôte lors de l'utilisation d'un routeur virtuel ou d'un logiciel NAT.

Notez que si vous devez appliquer la même stratégie réseau pour les processus hôtes et les pods, vous n'avez pas besoin d'utiliser l'option ApplyOnForward. Il vous suffit de créer une étiquette pour le point de terminaison hôte et le point de terminaison de charge de travail (pod) souhaités. Calico est suffisamment intelligent pour appliquer des stratégies basées sur des étiquettes, quel que soit le type de point de terminaison (point de terminaison hôte ou charge de travail).

Politique PreDNAT (4)


Dans Kubernetes, les ports de l'entité de service peuvent être transférés vers l'extérieur à l'aide de l'option NodePorts ou, facultativement (lorsque vous utilisez Calico), en les déclarant via les options IP de cluster ou IP externes. Kube-proxy équilibre le trafic entrant lié au service aux pods du service correspondant à l'aide de DNAT. Compte tenu de cela, comment appliquez-vous des politiques au trafic passant par NodePorts? Pour que ces politiques soient appliquées avant que le trafic ne soit traité par DNAT (qui est un mappage entre l'hôte: port et le service correspondant), Calico fournit un paramètre pour globalNetworkPolicy appelé "preDNAT: true".

Lorsque la pré-DNAT est activée, ces politiques sont implémentées en (4) dans le diagramme - dans la table mangle de la chaîne PREROUTING - immédiatement avant DNAT. La politique de commande habituelle n'est pas respectée ici, puisque l'application de ces politiques se produit beaucoup plus tôt le long du chemin de traitement du trafic. Cependant, les politiques preDNAT respectent l'ordre d'application entre elles.

Lors de la création de stratégies avec pré-DNAT, il est important de tenir compte du trafic que vous souhaitez traiter et de permettre à la plupart d'être rejeté. Le trafic marqué comme «autorisé» dans la stratégie pré-DNAT ne sera plus vérifié par la stratégie du point d'hôte, tandis que le trafic lorsque la stratégie pré-DNAT échoue continuera de circuler à travers le reste des chaînes.
Calico a rendu obligatoire l'activation de l'option applyOnForward lors de l'utilisation de preDNAT, car par définition, la destination du trafic n'a pas encore été sélectionnée. Le trafic peut être dirigé vers le processus hôte, ou il peut être redirigé vers un pod ou vers un autre nœud.

Politique non suivie (5)


Les réseaux et les applications peuvent avoir de grandes différences de comportement. Dans certains cas extrêmes, les applications peuvent générer de nombreuses connexions à court terme. Cela peut entraîner un manque de mémoire pour conntrack (le composant principal de la pile réseau Linux). Traditionnellement, pour exécuter ce type d'application sous Linux, vous devez configurer ou désactiver manuellement conntrack, ou écrire des règles iptables pour contourner conntrack. La stratégie non suivie dans Calico est une option plus simple et plus efficace si vous souhaitez traiter les connexions le plus rapidement possible. Par exemple, si vous utilisez un memcache massif ou comme mesure supplémentaire de protection contre DDOS .

Lisez cet article de blog (ou notre traduction) pour plus d'informations, y compris des tests de performances à l'aide de la stratégie non suivie.

Lorsque vous définissez l'option «doNotTrack: true» dans Calico globalNetworkPolicy, elle devient une stratégie ** non suivie ** et est appliquée au tout début du pipeline de traitement des packages Linux. Si vous regardez le diagramme ci-dessus, les stratégies non suivies sont appliquées dans les chaînes PREROUTING et OUTPUT de la table brute avant le démarrage du suivi de connexion (conntrack). Lorsqu'un package est autorisé par une stratégie non suivie, il est marqué pour désactiver le suivi de connexion pour ce package. Ça veut dire:

  • Une stratégie non suivie est appliquée pour chaque package. Il n'y a pas de concept de connexion (ou de flux). Le manque de connexions entraîne plusieurs conséquences importantes:
  • , , , ( Calico conntrack, ).
  • untracked workload Kubernetes (pod’), pod’.
  • NAT ( ​​ NAT conntrack).
  • « » untracked- . , , untracked- ( ).
  • Les politiques non suivies sont appliquées au tout début du pipeline de traitement des paquets. Ceci est très important à comprendre lors de la création de politiques Calico. Vous pouvez avoir une politique pour un module avec commande: 1 et une politique non suivie avec commande: 1000. Cela n'aura pas d'importance. La stratégie non suivie sera appliquée avant la stratégie du pod. Les politiques non suivies ne respectent l'ordre d'exécution qu'entre elles.

Étant donné que l'un des objectifs de la stratégie doNotTrack est d'appliquer la stratégie au tout début du pipeline de traitement des packages Linux, Calico rend obligatoire la spécification de l'option applyOnForward lors de l'utilisation de doNotTrack. En se référant au diagramme de traitement des paquets, notez que la politique non suivie (5) est appliquée avant toute décision de routage. Le trafic peut être dirigé vers le processus hôte, ou il peut être redirigé vers un pod ou vers un autre nœud.

Sommaire


Nous avons examiné les différentes options de stratégie (point de terminaison hôte, ApplyOnForward, preDNAT et Untracked) dans Calico et comment elles s'appliquent au traitement des paquets. Comprendre l'essence de leur travail aide à développer des politiques efficaces et sécurisées. Avec Calico, vous pouvez utiliser la stratégie de réseau globale, qui s'applique à l'étiquette (un groupe de nœuds et de pods) et appliquer des stratégies avec différents paramètres. Cela permet aux spécialistes de la sécurité et de la conception de réseaux de protéger immédiatement et «tout» (types de points de terminaison) en utilisant le même langage de politique que les politiques Calico.


Remerciements: Je tiens à remercier Sean Crampton et Alex Pollitt pour leur examen et leurs précieuses informations.

More articles:


All Articles