Le plugin réseau Calico fournit une large gamme de politiques réseau avec une syntaxe unifiée pour protéger les hôtes matériels, les machines virtuelles et les pods. Ces politiques peuvent être appliquées au sein d'un espace de noms ou être des politiques de réseau globales qui s'appliquent à (pour protéger les applications exécutées directement sur l'hôte - l'hôte peut être un serveur ou une machine virtuelle) ou (pour protéger les applications exécutées dans des conteneurs ou des machines virtuelles hébergées). Les politiques Calico vous permettent d'appliquer des mesures de sécurité à différents points du chemin d'un paquet à l'aide d'options telles que preDNAT, unraracked et applyOnForward. Comprendre le fonctionnement de ces options peut contribuer à améliorer la sécurité et les performances de l'ensemble de votre système. Cet article explique l'essence de ces options de politique Calico (preDNAT, unraracked et applyOnForward) appliquées aux points de terminaison hôtes, en mettant l'accent sur ce qui se passe dans les chemins de traitement des paquets (chaînes iptabels).
Cet article suppose que vous avez une compréhension de base du fonctionnement des stratégies réseau Kubernetes et Calico. Sinon, nous vous recommandons de l'essayer и utiliser Calico avant de lire cet article. Nous attendons également de vous que vous ayez une compréhension de base du travail sous linux.
Calicot vous permet d'appliquer un ensemble de règles d'accès par é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 du matériel ou une infrastructure Kubernetes. De plus, vous pouvez protéger votre cluster (nœuds) à l'aide d'un ensemble de politiques déclaratives et appliquer des politiques réseau au trafic entrant (par exemple, via le service NodePorts ou IP externes).
À un niveau fondamental, lorsque Calico connecte un pod au réseau (voir schéma ci-dessous), il le connecte à l'hôte à l'aide d'une interface Ethernet virtuelle (veth). Le trafic envoyé par le pod arrive à l'hôte depuis cette interface virtuelle et est traité de la même manière que s'il provenait d'une interface réseau physique. Par défaut, Calico nomme ces interfaces caliXXX. Étant donné que le trafic passe par l'interface virtuelle, il passe par iptables comme si le pod était à un saut. Par conséquent, lorsque le trafic arrive vers/depuis un pod, il est transféré du point de vue de l'hôte.
Sur un nœud Kubernetes exécutant Calico, vous pouvez mapper une interface virtuelle (veth) à une 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 politiques ? Pour ce faire, Calico crée des hooks dans diverses chaînes du chemin de traitement des paquets à 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. Une décision de routage est ensuite prise et, sur cette base, le paquet passe soit par INPUT (dirigé vers les processus hôtes), soit par FORWARD (dirigé vers un pod ou un autre nœud du réseau). A partir du processus local, le paquet passe par la chaîne OUTPUT puis POSTROUTING avant d'être envoyé sur le câble.
Notez que le pod est également une entité externe (connectée au veth) en termes de traitement iptables. Résumons :
- Le trafic transféré (nat, routé ou vers/depuis un 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 propose des options de stratégie qui vous permettent d'appliquer des stratégies sur toutes les chaînes. Dans cet esprit, examinons les différentes options de configuration de stratégie disponibles dans Calico. Les numéros dans la liste d'options ci-dessous correspondent aux numéros dans le diagramme ci-dessus.
- Stratégie de point de terminaison (pod) de charge de travail
- Politique de point de terminaison hôte
- Option AppliquerOnForward
- Politique préDNAT
- Politique non suivie
Commençons par examiner comment les stratégies sont appliquées aux points de terminaison de charge de travail (pods Kubernetes ou machines virtuelles OpenStack), puis examinons les options de stratégie pour les points de terminaison hôtes.
Points de terminaison de la charge de travail
Politique 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 l'utilisation de Kubernetes NetworkPolicy, mais fournit également des stratégies 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 de l'hôte
Politique de point de terminaison hôte (2)
En plus du CNI (interface réseau de conteneur), les politiques Calico offrent la possibilité de protéger l'hôte lui-même. 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 à l'aide d'une table de filtrage dans les chaînes INPUT et OUTPUT. Comme vous pouvez le voir sur le diagramme, (2) ils s'appliquent aux processus locaux sur le nœud/hôte. Autrement dit, si vous créez une stratégie qui s'applique au point de terminaison hôte, elle n'affectera pas le trafic allant vers/depuis vos pods. Mais il fournit une interface/syntaxe unique pour bloquer le trafic de votre hôte et de vos pods à l'aide des politiques Calico. Cela simplifie grandement le processus de gestion des politiques pour un réseau hétérogène. La configuration des politiques de point de terminaison hôte pour améliorer la sécurité du cluster est un autre cas d'utilisation important.
Politique ApplyOnForward (3)
L'option ApplyOnForward est disponible dans la stratégie réseau globale Calico pour permettre l'application des stratégies à tout le trafic passant par le point de terminaison de l'hôte, y compris le trafic qui sera transféré par l'hôte. Cela inclut le trafic transféré vers le pod local ou n’importe où ailleurs sur le réseau. Calico nécessite que ce paramètre soit activé pour les stratégies utilisant PreDNAT et non suivies, voir les sections suivantes. De plus, ApplyOnForward peut être utilisé pour surveiller le trafic hôte dans les cas où un routeur virtuel ou un NAT logiciel est utilisé.
Notez que si vous devez appliquer la même stratégie réseau aux processus hôtes et aux pods, vous n'avez pas besoin d'utiliser l'option ApplyOnForward. Tout ce que vous avez à faire est de créer une étiquette pour le point de terminaison d'hôte et le point de terminaison de charge de travail (pod) requis. Calico est suffisamment intelligent pour appliquer une politique basée sur des étiquettes, quel que soit le type de point de terminaison (point de terminaison hôte ou charge de travail).
Politique préDNAT (4)
Dans Kubernetes, les ports des entités de service peuvent être exposés en externe à l'aide de l'option NodePorts ou, éventuellement (lors de l'utilisation de Calico), en les annonçant à l'aide des options Cluster IPs ou External IPs. Kube-proxy équilibre le trafic entrant lié à un service vers les pods du service correspondant à l'aide de DNAT. Compte tenu de cela, comment appliquez-vous des politiques pour le trafic provenant de NodePorts ? Pour garantir que ces politiques sont appliquées avant que le trafic ne soit traité par DNAT (qui est un mappage entre hôte : port et service correspondant), Calico fournit un paramètre pour globalNetworkPolicy appelé « preDNAT : true ».
Lorsque pré-DNAT est activé, ces politiques sont implémentées en (4) dans le diagramme - dans la table mangle de la chaîne PREROUTING - immédiatement avant DNAT. L'ordre habituel des politiques n'est pas suivi ici, puisque l'application de ces politiques se produit beaucoup plus tôt dans le chemin de traitement du trafic. Cependant, les politiques preDNAT respectent l’ordre d’application entre elles.
Lors de la création de politiques avec pré-DNAT, il est important de faire attention au trafic que vous souhaitez traiter et de permettre que la majorité soit rejetée. Le trafic marqué comme « autoriser » dans la politique pré-DNAT ne sera plus vérifié par la politique du point d'hôte, tandis que le trafic qui échoue à la politique pré-DNAT continuera à travers les chaînes restantes.
Calico a rendu obligatoire l'activation de l'option applyOnForward lors de l'utilisation de preDNAT, puisque 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 vers un pod ou un autre nœud.
Politique non suivie (5)
Les réseaux et les applications peuvent présenter de grandes différences de comportement. Dans certains cas extrêmes, les applications peuvent générer de nombreuses connexions de courte durée. Cela peut entraîner un manque de mémoire pour conntrack (un composant essentiel de la pile réseau Linux). Traditionnellement, pour exécuter ces types d'applications sous Linux, vous deviez configurer ou désactiver manuellement conntrack, ou écrire des règles iptables pour contourner conntrack. La politique 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 massivement ou comme mesure supplémentaire de protection contre .
Lis ça (ou ) pour plus d'informations, y compris les tests de performances utilisant une 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 très tôt dans le pipeline de traitement des paquets Linux. En regardant le diagramme ci-dessus, les politiques 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 paquet est autorisé par la stratégie non suivi, il est marqué pour désactiver le suivi de connexion pour ce paquet. Ça veut dire:
- La politique de non-suivi est appliquée paquet par paquet. Il n’y a pas de notion de connexion (ou de flux). Le manque de connexions a plusieurs conséquences importantes :
- Si vous souhaitez autoriser à la fois le trafic de requêtes et de réponses, vous avez besoin d'une règle pour les appels entrants et sortants (puisque Calico utilise généralement conntrack pour marquer le trafic de réponse comme autorisé).
- La stratégie non suivie ne fonctionne pas pour les charges de travail Kubernetes (pods), car dans ce cas, il n'existe aucun moyen de suivre la connexion sortante depuis le pod.
- NAT ne fonctionne pas correctement avec les paquets non suivis (puisque le noyau stocke le mappage NAT dans conntrack).
- Lors du passage par la règle « tout autoriser » dans la stratégie non suivi, tous les paquets seront marqués comme non suivis. Ce n'est presque toujours pas ce que vous souhaitez, il est donc important d'être très sélectif quant aux paquets autorisés par les politiques non suivies (et de permettre à la plupart du trafic de passer par les politiques suivies normales).
- Les politiques non suivies sont appliquées au tout début du pipeline de traitement des paquets. Il est très important de comprendre cela lors de la création de politiques Calico. Vous pouvez avoir une stratégie de pod avec order:1 et une stratégie non suivie avec order:1000. Cela n'aura pas d'importance. La stratégie Non suivi sera appliquée avant la stratégie du pod. Les politiques non suivies respectent l’ordre d’exécution uniquement entre elles.
Étant donné que l'un des objectifs de la stratégie doNotTrack est d'appliquer la stratégie très tôt dans le pipeline de traitement des paquets Linux, Calico rend obligatoire la spécification de l'option applyOnForward lors de l'utilisation de doNotTrack. En vous référant au diagramme de traitement des paquets, notez que la politique untracked(5) est appliquée avant toute décision de routage. Le trafic peut être dirigé vers le processus hôte ou vers un pod ou un autre nœud.
Les résultats de
Nous avons examiné les différentes options de stratégie (point de terminaison hôte, ApplyOnForward, preDNAT et Untracked) dans Calico et la manière dont elles sont appliquées tout au long du chemin de traitement des paquets. Comprendre leur fonctionnement aide à élaborer des politiques efficaces et sûres. Avec Calico, vous pouvez utiliser une politique de réseau globale qui s'applique à une étiquette (un groupe de nœuds et de pods) et appliquer des politiques avec divers paramètres. Cela permet aux professionnels de la sécurité et de la conception de réseaux de protéger facilement « tout » (types de points de terminaison) en même temps en utilisant un langage de politique unique avec les politiques Calico.
Remerciement : je tiens à remercier и pour leur avis et leurs précieuses informations.
Source: habr.com