Le plugin réseau Calico offre un large éventail de politiques réseau avec une syntaxe unifiée pour protéger les hôtes sur matériel, machines virtuelles et pods. Ces politiques peuvent être appliquées au sein d'un namespace ou être des politiques réseau globales, applicables à (pour protéger les applications fonctionnant directement sur l'hôte — l'hôte peut être soit un serveur soit une machine virtuelle) ou à (pour protéger les applications fonctionnant dans des conteneurs ou des machines virtuelles hébergées sur l'hôte). Les politiques Calico permettent d'appliquer des mesures de sécurité pour différents points de chemin de paquets grâce à des options telles que preDNAT, unraracked 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'essentiel de ces paramètres de politique Calico (preDNAT, unraracked et applyOnForward) appliqués aux endpoints d'hôte, en mettant l'accent sur ce qui se passe dans les chemins de traitement des paquets (chaines iptables).
Cet article suppose que vous avez une compréhension des principes de base des politiques réseau Kubernetes et Calico. Si ce n'est pas le cas, nous vous recommandons d'essayer et à l'aide de Calico, avant de lire cet article. Nous nous attendons également à ce que vous ayez une compréhension de base du fonctionnement de sous Linux.
Calico vous permet d'appliquer un ensemble de règles d'accès par labels (à des groupes d'hôtes et de workloads/pods). C'est très utile si vous utilisez ensemble des systèmes hétérogènes — machines virtuelles, système sur matériel direct ou infrastructure Kubernetes. De plus, vous pouvez protéger votre cluster (nœuds) avec un ensemble de politiques déclaratives et appliquer des politiques réseau au trafic entrant (par exemple, via le service NodePorts ou les IP externes).
Au niveau fondamental, lorsque Calico connecte un pod au réseau (voir le diagramme ci-dessous), il le relie à l'hôte via une interface Ethernet virtuelle (veth). Le trafic envoyé par le pod arrive sur l'hôte par cette interface virtuelle et est traité comme s'il provenait d'une interface réseau physique. Par défaut, Calico nomme ces interfaces caliXXX. Comme le trafic passe par l'interface virtuelle, il traverse les iptables comme si le pod était à un saut de distance. Ainsi, lorsque le trafic arrive ou sort du pod, il est redirigé du point de vue de l'hôte.
Sur le nœud Kubernetes où Calico est exécuté, vous pouvez faire correspondre l'interface virtuelle (veth) avec le workload de la manière suivante. 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: 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
... 
Sachant que Calico crée une interface veth pour chaque workload, comment applique-t-il les politiques ? Pour cela, Calico crée des hooks dans différentes chaînes de parcours de traitement des paquets, en utilisant iptables.
Le diagramme ci-dessous montre les chaînes impliquées dans le traitement des paquets dans iptables (ou dans la sous-système netfilter). Lorsque le paquet arrive par l'interface réseau, il passe d'abord par la chaîne PREROUTING. Ensuite, une décision de routage est prise, et en fonction de cela, le paquet passe soit par INPUT (dirigé vers les processus de l'hôte), soit par FORWARD (dirigé vers un pod ou un autre nœud dans le réseau). À partir d'un processus local, le paquet passe par la chaîne OUTPUT, puis par POSTROUTING avant d'être envoyé par câble.
Notez que le pod est également un objet externe (connecté à veth) du point de vue du traitement des iptables. Résumons :
- Le trafic redirigé (forwarded) (nat, routable ou vers/depuis le pod) passe par les chaînes PREROUTING — FORWARD — POSTROUTING.
- Le trafic vers un processus hôte local passe par la chaîne PREROUTING — INPUT.
- Le trafic d'un processus hôte local passe par la chaîne OUTPUT — POSTROUTING.
Calico offre des options pour les politiques, permettant d'appliquer des politiques à toutes les chaînes. Gardant cela à l'esprit, examinons les différentes options de configuration des politiques disponibles dans Calico. Les chiffres de la liste des options ci-dessous correspondent à ceux du diagramme ci-dessus.
- Politique de point de terminaison de workload (pod)
- Politique de point de terminaison d'hôte
- Option ApplyOnForward
- Politique PreDNAT
- Politique Non Traquée
Commençons par examiner comment les politiques sont appliquées aux points de terminaison de workload (pods Kubernetes ou VMs OpenStack), puis examinons les options de politique pour les points de terminaison d'hôte.
Points de terminaison de workload
Politique de point de terminaison de workload (1)
C'est une option pour protéger vos pods Kubernetes. Calico prend en charge le travail avec Kubernetes NetworkPolicy, mais fournit également des politiques supplémentaires — Calico NetworkPolicy et GlobalNetworkPolicy. Calico crée une chaîne pour chaque pod (workload) et des hooks dans les chaînes INPUT et OUTPUT pour le workload vers la table de filtrage de la chaîne FORWARD.
Points de terminaison d'hôte
Politique de point de terminaison d'hôte (2)
En plus du CNI (interface réseau de conteneur), les politiques Calico offrent la possibilité de protéger directement l'hôte. Dans Calico, vous pouvez créer un point de terminaison d'hôte en définissant une combinaison de l'interface de l'hôte et, si nécessaire, de numéros de port. L'application des politiques pour cette entité se fait via la table de filtrage dans les chaînes INPUT et OUTPUT. Comme indiqué dans le diagramme, (2) elles s'appliquent aux processus locaux sur le nœud/hôte. C'est-à-dire que si vous avez créé une politique qui s'applique à un point de terminaison d'hôte, elle n'affectera pas le trafic allant vers/en provenance de vos pods. Cependant, elle permet d'avoir 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 des politiques de points de terminaison d'hôte pour renforcer la sécurité du cluster est un autre cas important de leur utilisation.
Politique ApplyOnForward (3)
L'option ApplyOnForward est disponible dans la politique de réseau global Calico, pour permettre l'application des politiques sur tout le trafic circulant via le point de terminaison d'hôte, y compris le trafic qui sera transféré par l'hôte (forwarded). Ce trafic inclut celui redirigé vers un pod local ou ailleurs sur le réseau. Calico exige que ce paramètre soit activé pour les politiques utilisant PreDNAT et non suivies, voir les sections suivantes. De plus, ApplyOnForward peut être utilisé pour suivre le trafic de l'hôte dans les cas d'utilisation d'un routeur virtuel ou d'un NAT logiciel.
Notez que si vous devez appliquer la même politique réseau tant pour les processus hôtes que pour les pods, il n'est pas nécessaire d'utiliser l'option ApplyOnForward. Il vous suffit de créer un label pour les hostendpoints et les workload endpoints (pods) concernés. Calico est assez intelligent pour appliquer la politique en fonction des labels, quel que soit le type d'endpoint (hostendpoint ou workload).
Policy PreDNAT (4)
Dans Kubernetes, les ports de l'entité service peuvent être exposés à l'extérieur via l'option NodePorts ou, en option (lors de l'utilisation de Calico), par leur déclaration via les options Cluster IPs ou External IPs. Kube-proxy équilibre le trafic entrant associé au service vers les pods des services correspondants, en utilisant DNAT. En tenant compte de cela, comment appliquerez-vous les politiques pour le trafic entrant par les NodePorts ? Pour que ces politiques soient appliquées avant que le trafic ne soit traité par DNAT (qui est une correspondance entre l'hôte : port et le service correspondant), Calico fournit un paramètre pour le globalNetworkPolicy appelé « preDNAT: true ».
Lorsque le pre-DNAT est activé, ces politiques sont mises en œuvre en (4) sur le diagramme — dans la chaîne mangle de la table PREROUTING — juste avant le DNAT. L'ordre normal des politiques (order) n'est pas respecté ici, car l'application de ces politiques se produit bien plus tôt dans le chemin de traitement du trafic. Cependant, les politiques preDNAT respectent l'ordre d'application (order) entre elles.
Lors de la création de politiques avec pre-DNAT, il est important de faire attention au trafic que vous souhaitez traiter et de permettre au plus grand nombre d'être rejeté. Le trafic étiqueté comme 'allow' dans la politique pre-DNAT ne sera plus vérifié par la politique d'hostendpoint, tandis que le trafic échouant à passer la politique pre-DNAT continuera son chemin à travers les autres 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'est pas encore choisie. Le trafic peut être dirigé vers le processus hôte, ou il peut être redirigé vers un pod ou vers un autre nœud.
Policy Untracked (5)
Les réseaux et les applications peuvent se comporter très différemment. Dans certains cas extrêmes, les applications peuvent générer de nombreuses connexions temporaires. Cela peut entraîner un manque de mémoire pour conntrack (le composant de base de la pile réseau Linux). Traditionnellement, pour exécuter des applications de ce type sous Linux, vous devez configurer manuellement ou désactiver conntrack, ou écrire des règles iptables pour contourner conntrack. La politique non suivie dans Calico est une option plus simple et efficace si vous souhaitez gérer les connexions aussi rapidement que possible. Par exemple, si vous utilisez un grand ou comme mesure de protection supplémentaire contre .
Lisez cet ou ) pour plus d'informations, y compris des tests de performance lors de l'utilisation d'une politique non suivie.
Lorsque vous définissez l'option « doNotTrack: true » dans Calico globalNetworkPolicy, elle devient une politique **non suivie** et s'applique dès le début du pipeline de traitement des paquets Linux. Si vous regardez le diagramme ci-dessus, les politiques non suivies sont appliquées dans les chaînes PREROUTING et OUTPUT de la table raw, avant que le suivi des connexions (conntrack) ne commence. Lorsqu'un paquet est autorisé par la politique non suivie, il est marqué pour désactiver le suivi des connexions pour ce paquet. Cela signifie :
- La politique non suivie s'applique à chaque paquet. Il n'y a pas de concept de connexion (ou de flux). L'absence de connexions entraîne plusieurs conséquences importantes :
- Si vous souhaitez autoriser à la fois le trafic de requête et le trafic de réponse, vous devez avoir une règle pour le trafic entrant ainsi que pour le trafic sortant (car Calico utilise généralement conntrack pour marquer le trafic de réponse comme autorisé).
- La politique non suivie ne fonctionne pas pour les workloads Kubernetes (pods), car dans ce cas il n'y a aucun moyen de suivre une connexion sortante à partir d'un pod.
- Le NAT fonctionne incorrectement avec des paquets non suivis (car le noyau garde la correspondance NAT dans conntrack).
- Lorsqu'un paquet passe par la règle « autoriser tout » dans la politique non suivie, tous les paquets seront marqués comme non suivis. Cela n'est presque jamais ce dont vous avez besoin, il est donc important d'être très sélectif avec les paquets autorisés par les politiques non suivies (et de permettre à la majeure partie 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 politique pour un pod avec order:1 et une politique non suivie avec order:1000. Cela n'aura pas d'importance. La politique non suivie sera appliquée avant la politique pour le pod. Les politiques non suivies respectent uniquement l'ordre d'exécution entre elles.
Étant donné qu'un des objectifs de la politique doNotTrack est d'assurer l'application de la politique à un stade précoce du pipeline de traitement des paquets Linux, Calico rend obligatoire le 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 un processus hôte, ou il peut être redirigé vers un pod ou un autre nœud.
Résultats
Nous avons examiné diverses options de politiques (point de terminaison hôte, ApplyOnForward, preDNAT et Non suivi) dans Calico et comment elles sont appliquées dans le chemin de traitement des paquets. Comprendre leur fonctionnement essentiel aide à développer des politiques efficaces et sécurisées. Avec Calico, vous pouvez utiliser une politique réseau globale qui s'applique à un label (groupe de nœuds et de pods) et appliquer des politiques avec différents paramètres. Cela permet aux spécialistes de la sécurité et de la conception réseau de protéger facilement "tout" (types de points de terminaison) en utilisant un langage de politique uniforme avec les politiques Calico.
Remerciements : Je tiens à remercier et pour leur révision et pour leurs informations précieuses.
Source : habr.com
