Introduction aux stratégies de réseau Kubernetes pour les professionnels de la sécurité

Remarque perev. : L'auteur de l'article - Reuven Harrison - a plus de 20 ans d'expérience dans le développement de logiciels, et est aujourd'hui le directeur technique et co-fondateur de Tufin, une entreprise qui crée des solutions de gestion des politiques de sécurité. Considérant les stratégies de réseau Kubernetes comme un outil suffisamment puissant pour la segmentation du réseau dans un cluster, il pense qu'elles ne sont pas si faciles à appliquer dans la pratique. Ce matériau (plutôt volumineux) est conçu pour améliorer les connaissances des spécialistes en la matière et les aider à créer les configurations nécessaires.

Aujourd'hui, de nombreuses entreprises choisissent de plus en plus Kubernetes pour exécuter leurs applications. L'intérêt pour ce logiciel est si élevé que certains appellent Kubernetes "le nouveau système d'exploitation du centre de données". Progressivement, Kubernetes (ou k8s) commence à être perçu comme un élément essentiel de l'entreprise, ce qui nécessite l'organisation de processus métier matures, y compris la sécurité du réseau.

Pour les professionnels de la sécurité qui sont perplexes en travaillant avec Kubernetes, la politique par défaut de cette plate-forme peut être une véritable découverte: tout autoriser.

Ce guide vous aidera à comprendre la structure interne des stratégies réseau; Comprenez en quoi elles diffèrent des règles des pare-feu ordinaires. Certains pièges seront également décrits et des recommandations seront données pour aider à protéger les applications dans Kubernetes.

Stratégies de réseau Kubernetes

Le mécanisme de stratégie de réseau de Kubernetes vous permet de contrôler l'interaction des applications déployées sur la plate-forme au niveau du réseau (la troisième dans le modèle OSI). Les stratégies réseau ne disposent pas de certaines des fonctionnalités avancées des pare-feu modernes, telles que la surveillance OSI niveau 7 et la détection des menaces, mais elles offrent un niveau de sécurité réseau de base, ce qui est un bon point de départ.

Les stratégies réseau contrôlent les communications entre les pods

Les charges de travail Kubernetes sont réparties sur des pods composés d'un ou de plusieurs conteneurs déployés ensemble. Kubernetes attribue à chaque pod une adresse IP accessible à partir d'autres pods. Les stratégies réseau de Kubernetes définissent les autorisations pour les groupes de pods de la même manière que les groupes de sécurité dans le cloud sont utilisés pour contrôler l'accès aux instances de machine virtuelle.

Définition des stratégies réseau

Comme les autres ressources Kubernetes, les stratégies réseau sont définies dans YAML. Dans l'exemple ci-dessous, balance accès aux postgres :

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.postgres namespace: default spec: podSelector: matchLabels: app: postgres ingress: - from: - podSelector: matchLabels: app: balance policyTypes: - Ingress 

( Remarque : cette capture d'écran, comme toutes les suivantes, n'a pas été créée à l'aide des outils natifs de Kubernetes, mais à l'aide de l'outil Tufin Orca, qui est développé par l'auteur de l'article d'origine et mentionné à la fin de l'article.)

La définition de votre propre stratégie réseau nécessitera des connaissances de base en YAML. Cette langue est basée sur l'indentation (spécifiée par des espaces, pas des tabulations). Un élément en retrait appartient à l'élément en retrait le plus proche au-dessus de lui. Un nouvel élément de liste commence par un tiret, tous les autres éléments sont des valeurs-clés .

Après avoir décrit la stratégie dans YAML, utilisez kubectl pour la créer dans le cluster:

 kubectl create -f policy.yaml 

Spécifications de stratégie réseau

La spécification de stratégie réseau Kubernetes comprend quatre éléments:

1. podSelector : définit les pods concernés par cette politique (objectifs) - obligatoire;
2. policyTypes : indique quels types de politiques sont inclus dans ceci: entrée et / ou sortie - facultatif, cependant, je vous recommande de l'enregistrer explicitement dans tous les cas;
3. ingress : définit le trafic entrant autorisé vers les pods cibles - facultatif;
4. egress : définit le trafic sortant autorisé des pods cibles - facultatif.

Un exemple emprunté au site Web de Kubernetes (j'ai remplacé le role par l' app ) montre comment les quatre éléments sont utilisés:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy namespace: default spec: podSelector: # <<< matchLabels: app: db policyTypes: # <<< - Ingress - Egress ingress: # <<< - from: - ipBlock: cidr: 172.17.0.0/16 except: - 172.17.1.0/24 - namespaceSelector: matchLabels: project: myproject - podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 6379 egress: # <<< - to: - ipBlock: cidr: 10.0.0.0/24 ports: - protocol: TCP port: 5978 

Veuillez noter que les quatre éléments sont facultatifs. Seul podSelector est podSelector , d'autres paramètres peuvent être utilisés à votre guise.

Si vous omettez policyTypes , la politique sera interprétée comme suit:

• Par défaut, il est supposé qu'il définit le côté d'entrée. Si la politique ne l'indique pas explicitement, le système considérera que tout trafic est interdit.
• Le comportement du côté sortie sera déterminé par la présence ou l'absence du paramètre de sortie correspondant.

Pour éviter les erreurs, je recommande de toujours spécifier explicitement policyTypes .

Conformément à la logique ci-dessus, si les egress ingress et / ou de egress sont omis, la politique interdira tout le trafic (voir "Règle de suppression" ci-dessous).

La politique par défaut consiste à autoriser

Si aucune stratégie n'est définie, Kubernetes autorise par défaut tout le trafic. Tous les pods sont libres d'échanger des informations entre eux. D'un point de vue de la sécurité, cela peut sembler contre-intuitif, mais n'oubliez pas que Kubernetes a été créé à l'origine par les développeurs afin d'assurer l'interopérabilité des applications. Des stratégies réseau ont été ajoutées ultérieurement.

Espaces de noms

Les espaces de noms sont un mécanisme collaboratif de Kubernetes. Ils sont conçus pour isoler les environnements logiques les uns des autres, tandis que l'échange de données entre les espaces est autorisé par défaut.

Comme la plupart des composants Kubernetes, les stratégies réseau résident dans un espace de noms spécifique. Dans le bloc de metadata , vous pouvez spécifier à quel espace appartient la stratégie:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy namespace: my-namespace # <<< spec: ... 

Si l'espace de noms n'est pas explicitement écrit dans les métadonnées, le système utilisera l'espace de noms spécifié dans kubectl (par défaut namespace=default ):

 kubectl apply -n my-namespace -f namespace.yaml 

Je recommande de spécifier explicitement un espace de noms, sauf si vous écrivez une stratégie destinée à plusieurs espaces de noms à la fois.

L' élément podSelector principal d' une stratégie sélectionne les pods de l'espace de noms auquel appartient la stratégie (l'accès aux pods d'un autre espace de noms lui est refusé).

De même, podSelectors dans les blocs d'entrée et de sortie ne peut sélectionner les pods que dans leur espace de noms, sauf si, bien sûr, vous les combinez avec namespaceSelector (cela sera discuté dans la section «Filtrage par namespace et pods») .

Règles de dénomination des stratégies

Les noms de stratégie sont uniques dans un seul espace de noms. Il ne peut pas y avoir deux politiques portant le même nom dans un espace, mais il peut y avoir des politiques portant le même nom dans des espaces différents. Ceci est utile lorsque vous souhaitez réappliquer la même stratégie sur plusieurs espaces.

J'aime particulièrement une façon de nommer. Il consiste à combiner le nom de l'espace de noms avec les pods cibles. Par exemple:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.postgres # <<< namespace: default spec: podSelector: matchLabels: app: postgres ingress: - from: - podSelector: matchLabels: app: admin policyTypes: - Ingress 

Les étiquettes

Des étiquettes personnalisées peuvent être attachées aux objets Kubernetes, tels que les pods et les espaces de noms. Les étiquettes sont l'équivalent des balises dans le cloud. Les stratégies de réseau Kubernetes utilisent des étiquettes pour sélectionner les modules auxquels elles s'appliquent:

 podSelector: matchLabels: role: db 

... ou les espaces de noms auxquels ils s'appliquent. Dans cet exemple, tous les pods dans les espaces de noms avec les étiquettes correspondantes sont sélectionnés:

 namespaceSelector: matchLabels: project: myproject 

Une mise en garde: lorsque vous utilisez namespaceSelector assurez-vous que les namespaceSelector vous sélectionnez contiennent le libellé souhaité . Gardez à l'esprit que les espaces de noms intégrés tels que default et kube-system ne contiennent pas d'étiquettes par défaut.

Vous pouvez ajouter une étiquette à l'espace comme suit:

 kubectl label namespace default namespace=default 

Dans ce cas, l'espace de noms dans la section des metadata doit faire référence au nom réel de l'espace et non à l'étiquette:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy namespace: default # <<< spec: ... 

Source et destination

Les politiques pour les pare-feu consistent en des règles avec des sources et des destinations. Les stratégies de réseau Kubernetes sont définies à cet effet - un ensemble de pods auxquels elles sont appliquées, puis établissent des règles pour le trafic entrant (entrant) et / ou sortant (sortant). Dans notre exemple, la cible de la stratégie sera tous les pods dans l'espace de noms default avec une étiquette avec la clé d' app et la valeur db :

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy namespace: default spec: podSelector: matchLabels: app: db # <<< policyTypes: - Ingress - Egress ingress: - from: - ipBlock: cidr: 172.17.0.0/16 except: - 172.17.1.0/24 - namespaceSelector: matchLabels: project: myproject - podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 6379 egress: - to: - ipBlock: cidr: 10.0.0.0/24 ports: - protocol: TCP port: 5978 

La sous-section d' ingress de cette stratégie ouvre le trafic entrant aux pods cibles. En d'autres termes, l'entrée est la source et la cible est le destinataire approprié. De même, la sortie est la cible et la cible est sa source.



Cela équivaut à deux règles pour le pare-feu: Ingress → Target; Objectif → Sortie.

Sortie et DNS (important!)

Lorsque vous limitez le trafic sortant, portez une attention particulière au DNS - Kubernetes utilise ce service pour mapper les services aux adresses IP. Par exemple, la stratégie suivante ne fonctionnera pas car vous n'avez pas autorisé l'application balance à accéder au DNS:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.balance namespace: default spec: podSelector: matchLabels: app: balance egress: - to: - podSelector: matchLabels: app: postgres policyTypes: - Egress 

Vous pouvez le corriger en ouvrant l'accès au service DNS:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.balance namespace: default spec: podSelector: matchLabels: app: balance egress: - to: - podSelector: matchLabels: app: postgres - to: # <<< ports: # <<< - protocol: UDP # <<< port: 53 # <<< policyTypes: - Egress 

Le dernier élément to est vide et, par conséquent, il sélectionne indirectement tous les pods dans tous les espaces de noms , ce qui permet à balance envoyer des requêtes DNS au service Kubernetes correspondant (il fonctionne généralement dans l'espace du kube-system Kube).

Cette approche fonctionne, mais elle est trop permissive et peu sûre , car elle vous permet de diriger des requêtes DNS en dehors du cluster.

Vous pouvez l'améliorer en trois étapes consécutives.

1. Autorisez les requêtes DNS uniquement au sein du cluster en ajoutant namespaceSelector :

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.balance namespace: default spec: podSelector: matchLabels: app: balance egress: - to: - podSelector: matchLabels: app: postgres - to: - namespaceSelector: {} # <<< ports: - protocol: UDP port: 53 policyTypes: - Egress 

2. Autorisez les requêtes DNS uniquement dans l'espace de noms kube-system .

Pour ce faire, ajoutez une étiquette à l' kubectl label namespace kube-system namespace=kube-system kube-system : kubectl label namespace kube-system namespace=kube-system - et enregistrez-le dans la stratégie à l'aide de namespaceSelector :

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.balance namespace: default spec: podSelector: matchLabels: app: balance egress: - to: - podSelector: matchLabels: app: postgres - to: - namespaceSelector: # <<< matchLabels: # <<< namespace: kube-system # <<< ports: - protocol: UDP port: 53 policyTypes: - Egress 

3. Les paranoïdes peuvent aller encore plus loin et limiter les requêtes DNS à un service DNS spécifique dans le kube-system . Dans la section «Filtrer par espaces de noms et modules», nous expliquerons comment y parvenir.

Une autre option consiste à résoudre DNS au niveau de l'espace de noms. Dans ce cas, il n'aura pas besoin d'être ouvert pour chaque service:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.dns namespace: default spec: podSelector: {} # <<< egress: - to: - namespaceSelector: {} ports: - protocol: UDP port: 53 policyTypes: - Egress 

Un podSelector vide sélectionne tous les pods de l'espace de noms.

Premier match et ordre des règles

Dans les pare-feu ordinaires, l'action ("Autoriser" ou "Refuser") pour un paquet est déterminée par la première règle qu'il satisfait. Dans Kubernetes, l'ordre des politiques n'a pas d'importance.

Par défaut, lorsque les stratégies ne sont pas définies, les communications entre les pods sont autorisées et elles peuvent échanger librement des informations. Dès que vous commencez à formuler des stratégies, chaque module affecté par au moins l'une d'entre elles est isolé conformément à la disjonction (OU logique) de toutes les stratégies qui l'ont choisi. Les pods qui ne sont affectés par aucune politique restent ouverts.

Vous pouvez modifier ce comportement à l'aide de la règle de suppression.

Règle de suppression (Refuser)

Les politiques de pare-feu interdisent généralement tout trafic explicitement non autorisé.

Kubernetes n'a pas d'action de refus , cependant, un effet similaire peut être obtenu avec une stratégie régulière (autorisant) en sélectionnant un groupe vide de pods source (entrée):

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all namespace: default spec: podSelector: {} policyTypes: - Ingress 

Cette stratégie sélectionne tous les pods dans l'espace de noms et laisse l'entrée non définie, bloquant tout le trafic entrant.

De même, vous pouvez limiter tout le trafic sortant de l'espace de noms:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all-egress namespace: default spec: podSelector: {} policyTypes: - Egress 

Notez que toutes les stratégies supplémentaires qui autorisent le trafic vers les pods dans l'espace de noms auront priorité sur cette règle (similaire à l'ajout d'une règle d'autorisation sur une règle de refus dans la configuration du pare-feu).

Tout autoriser (Any-Any-Any-Allow)

Pour créer une stratégie Autoriser tout, vous devez ajouter la stratégie d'interdiction ci-dessus avec un élément d' ingress vide:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all namespace: default spec: podSelector: {} ingress: # <<< - {} # <<< policyTypes: - Ingress 

Il permet l'accès de tous les pods dans tous les espaces de noms (et toutes les IP) à tous les pods de l'espace de noms default . Ce comportement est activé par défaut, il n'a donc généralement pas besoin d'être défini en plus. Cependant, il peut parfois être nécessaire de désactiver temporairement certaines autorisations spécifiques pour diagnostiquer le problème.

La règle peut être restreinte et n'autoriser l'accès qu'à un ensemble spécifique de modules ( app:balance ) dans l'espace de noms default :

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all-to-balance namespace: default spec: podSelector: matchLabels: app: balance ingress: - {} policyTypes: - Ingress 

La stratégie suivante autorise tout le trafic d'entrée et de sortie, y compris l'accès à toute adresse IP en dehors du cluster:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all spec: podSelector: {} ingress: - {} egress: - {} policyTypes: - Ingress - Egress 

Combiner plusieurs politiques

Les stratégies sont combinées à l'aide d'un OU logique à trois niveaux; les autorisations de chaque module sont définies en fonction de la disjonction de toutes les politiques qui l'affectent:

1. Dans les champs from et to , vous pouvez définir trois types d'éléments (tous sont combinés à l'aide de OR):

• namespaceSelector - sélectionne l'intégralité de l'espace de noms;
• podSelector - sélectionne les pods;
• ipBlock - sélectionne un sous-réseau.

De plus, le nombre d'éléments (même les mêmes) dans les from -sections from / to n'est pas limité. Tous seront combinés par OU logique.

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.postgres namespace: default spec: ingress: - from: - podSelector: matchLabels: app: indexer - podSelector: matchLabels: app: admin podSelector: matchLabels: app: postgres policyTypes: - Ingress 

2. À l'intérieur de la politique, la section d' ingress peut avoir plusieurs éléments (combinés par OU logique). De même, la section de egress peut inclure plusieurs éléments to (également joints par une clause):

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.postgres namespace: default spec: ingress: - from: - podSelector: matchLabels: app: indexer - from: - podSelector: matchLabels: app: admin podSelector: matchLabels: app: postgres policyTypes: - Ingress 

3. Diverses politiques sont également combinées par OU logique

Mais en les combinant, il y a une limitation que Chris Cooney a souligné : Kubernetes ne peut combiner que des politiques avec différents policyTypes ( Ingress ou Egress ). Les politiques qui définissent l'entrée (ou la sortie) se remplaceront mutuellement.

La relation entre les espaces de noms

Par défaut, l'échange d'informations entre les espaces de noms est autorisé. Cela peut être modifié en utilisant une politique prohibitive qui restreint le trafic sortant et / ou entrant dans l'espace de noms (voir "Règle de suppression" ci-dessus).

En bloquant l'accès à l'espace de noms (voir «Règle de suppression» ci-dessus), vous pouvez faire des exceptions à la politique restrictive en autorisant les connexions à partir d'un espace de noms spécifique à l'aide de namespaceSelector :

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: database.postgres namespace: database spec: podSelector: matchLabels: app: postgres ingress: - from: - namespaceSelector: # <<< matchLabels: namespace: default policyTypes: - Ingress 

Par conséquent, tous les pods de l'espace de noms default auront accès aux pods postgres de l'espace de noms de la database . Mais que faire si vous souhaitez ouvrir l'accès aux postgres uniquement à des pods spécifiques dans l'espace de noms default ?

Filtrer par espaces de noms et pods

Kubernetes version 1.11 et supérieure vous permet de combiner les opérateurs namespaceSelector et podSelector aide du I. logique. Il ressemble à ceci:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: database.postgres namespace: database spec: podSelector: matchLabels: app: postgres ingress: - from: - namespaceSelector: matchLabels: namespace: default podSelector: # <<< matchLabels: app: admin policyTypes: - Ingress 

Pourquoi est-il interprété comme ET au lieu du OU habituel?

Notez que podSelector ne commence pas par un trait d'union. En YAML, cela signifie que podSelector et le namespaceSelector tenant devant lui font référence au même élément de liste. Par conséquent, ils sont combinés par un I. logique.

L'ajout d'un trait d'union devant podSelector se traduira par un nouvel élément de liste qui sera combiné avec le namespaceSelector précédent à l'aide d'un OU logique.

Pour sélectionner des pods avec une étiquette spécifique dans tous les espaces de noms , entrez un namespaceSelector vide

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: database.postgres namespace: database spec: podSelector: matchLabels: app: postgres ingress: - from: - namespaceSelector: {} podSelector: matchLabels: app: admin policyTypes: - Ingress 

Plusieurs étiquettes se combinent avec AND

Les règles d'un pare-feu avec de nombreux objets (hôtes, réseaux, groupes) sont combinées à l'aide d'un OU logique. La règle suivante fonctionnera si la source du paquet correspond à Host_1 OU Host_2 :

 | Source | Destination | Service | Action | | ----------------------------------------| | Host_1 | Subnet_A | HTTPS | Allow | | Host_2 | | | | | ----------------------------------------| 

Inversement, dans Kubernetes, diverses étiquettes dans podSelector ou namespaceSelector sont combinées par I. logique. Par exemple, la règle suivante sélectionnera les pods qui ont les deux étiquettes, role=db AND version=v2 :

 podSelector: matchLabels: role: db version: v2 

La même logique s'applique à tous les types d'opérateurs: sélecteurs d'objectifs de stratégie, sélecteurs de pods et sélecteurs d'espace de noms.

Sous-réseaux et adresses IP (IPBlocks)

Les pare-feu utilisent des VLAN, des adresses IP et des sous-réseaux pour segmenter un réseau.

Dans Kubernetes, les adresses IP sont attribuées automatiquement aux pods et peuvent changer fréquemment, de sorte que les étiquettes sont utilisées pour sélectionner les pods et les espaces de noms dans les stratégies réseau.

ipBlocks - ipBlocks ( ipBlocks ) sont utilisés pour contrôler les connexions externes entrantes (entrées) ou sortantes (sorties) (Nord-Sud). Par exemple, cette stratégie donne à tous les pods de l'espace de noms default accès au service DNS de Google:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: egress-dns namespace: default spec: podSelector: {} policyTypes: - Egress egress: - to: - ipBlock: cidr: 8.8.8.8/32 ports: - protocol: UDP port: 53 

Le sélecteur de pod vide dans cet exemple signifie "sélectionner tous les pods dans l'espace de noms".

Cette politique ne donne accès qu'à 8.8.8.8; l'accès à toute autre adresse IP est refusé. Ainsi, vous avez essentiellement bloqué l'accès au service DNS interne de Kubernetes. Si vous souhaitez toujours l'ouvrir, spécifiez-le explicitement.

En général, ipBlocks et podSelectors s'excluent mutuellement, car les adresses IP internes des pods ne sont pas utilisées dans ipBlocks . En spécifiant les pods IP internes , vous autoriserez réellement les connexions vers / depuis les pods avec ces adresses. En pratique, vous ne saurez pas quelle adresse IP utiliser, c'est pourquoi elles ne doivent pas être utilisées pour sélectionner des pods.

À titre de contre-exemple, la stratégie suivante inclut toutes les adresses IP et, par conséquent, autorise l'accès à tous les autres pods:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: egress-any namespace: default spec: podSelector: {} policyTypes: - Egress egress: - to: - ipBlock: cidr: 0.0.0.0/0 

Vous ne pouvez ouvrir l'accès qu'aux IP externes en excluant les adresses IP internes des pods. Par exemple, si le sous-réseau de votre pod est 10.16.0.0/14:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: egress-any namespace: default spec: podSelector: {} policyTypes: - Egress egress: - to: - ipBlock: cidr: 0.0.0.0/0 except: - 10.16.0.0/14 

Ports et protocoles

Les pods écoutent généralement sur un port. Cela signifie que vous pouvez simplement omettre les numéros de port dans les stratégies et tout laisser par défaut. Cependant, il est recommandé de rendre les politiques aussi restrictives que possible, donc dans certains cas, vous pouvez toujours spécifier des ports:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.postgres namespace: default spec: ingress: - from: - podSelector: matchLabels: app: indexer - podSelector: matchLabels: app: admin ports: # <<< - port: 443 # <<< protocol: TCP # <<< - port: 80 # <<< protocol: TCP # <<< podSelector: matchLabels: app: postgres policyTypes: - Ingress 

Notez que le sélecteur de ports s'applique à tous les éléments from bloc to ou from qu'il contient. Pour spécifier différents ports pour différents ensembles d'éléments, divisez l' ingress ou la egress en plusieurs sous-sections avec ou from et répertoriez vos ports dans chacune:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.postgres namespace: default spec: ingress: - from: - podSelector: matchLabels: app: indexer ports: # <<< - port: 443 # <<< protocol: TCP # <<< - from: - podSelector: matchLabels: app: admin ports: # <<< - port: 80 # <<< protocol: TCP # <<< podSelector: matchLabels: app: postgres policyTypes: - Ingress 

Les ports par défaut fonctionnent:

• Si vous omettez complètement la définition des ports, cela signifie tous les protocoles et tous les ports;
• Si vous omettez la définition du protocole, cela signifie TCP;
• Si vous omettez la définition d'un port, cela signifie tous les ports.

Meilleure pratique: ne vous fiez pas aux valeurs par défaut, spécifiez explicitement ce dont vous avez besoin.

Veuillez noter qu'il est nécessaire d'utiliser des ports pod, pas des services (plus à ce sujet dans le paragraphe suivant).

Des stratégies sont-elles définies pour les modules ou les services?

En général, les pods de Kubernetes se contactent via un service - un équilibreur de charge virtuel qui redirige le trafic vers les pods qui implémentent le service. Vous pourriez penser que les stratégies réseau contrôlent l'accès aux services, mais ce n'est pas le cas. Les stratégies réseau de Kubernetes fonctionnent avec les ports pod, pas avec les services.

, 80- , 8080 pod', 8080.

: ( pod') .

Service Mesh (, . Istio — . .) .

Ingress, Egress?

— , pod pod' , ( egress-), pod ( , , ingress-).

, .

pod- egress -, . pod'- . pod - , (egress) .

pod'- , ingress -, . pod'-. pod - , (ingress) .

. «Stateful Stateless» .

Kubernetes . , , .

Kubernetes (DNS) egress. , IP- ( aws.com).

. Kubernetes . kubectl Kubernetes , , . Kubernetes . :

 kubernetes get networkpolicy <policy-name> -o yaml 

, Kubernetes .

Kubernetes , API-, , Container Networking Interface (CNI). Kubernetes CNI . CNI , Kubernetes, ( — . .) , , CNI .

, Kubernetes , CNI.

Stateful Stateless?

CNI Kubernetes, , (, Calico Linux conntrack). pod' TCP- . Kubernetes, (statefulness).

Kubernetes:

1. Service Mesh sidecar- . Istio .
2. CNI , Kubernetes.
3. Tufin Orca Kubernetes.

Tufin Orca Kubernetes ( , ).

Information additionnelle

• , Ahmet Alp Balkan' GKE ;
• Kubernetes ;
• Kubernetes ;
• .

Conclusion

Kubernetes , . , - . .

, , .

PS du traducteur

Lisez aussi dans notre blog:

• « Istio»: 1 ( ) , 2 (, ) , 3 () ;
• « Kubernetes»: 1 2 ( , ) , 3 ( ) ;
• « Docker Kubernetes »;
• « 9 Kubernetes »;
• « 11 () Kubernetes ».