Chapitre 20. Politique des réseaux

Refuser tout le trafic :

Pour qu'un projet soit refusé par défaut, ajoutez un objet NetworkPolicy qui correspond à tous les pods mais n'accepte aucun trafic :

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
spec:
  podSelector: {}
  ingress: []

N'autoriser que les connexions provenant du contrôleur d'entrée de la plate-forme OpenShift Container :

Pour qu'un projet n'autorise que les connexions provenant du contrôleur d'ingestion de la plate-forme OpenShift Container, ajoutez l'objet NetworkPolicy suivant.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-ingress
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network.openshift.io/policy-group: ingress
  podSelector: {}
  policyTypes:
  - Ingress

N'accepte que les connexions provenant de pods au sein d'un projet :

Pour que les pods acceptent les connexions d'autres pods du même projet, mais rejettent toutes les autres connexions de pods d'autres projets, ajoutez l'objet suivant NetworkPolicy:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector: {}

N'autoriser le trafic HTTP et HTTPS qu'en fonction des étiquettes de pods :

Pour permettre uniquement l'accès HTTP et HTTPS aux pods avec un label spécifique (role=frontend dans l'exemple suivant), ajoutez un objet NetworkPolicy similaire à ce qui suit :

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-http-and-https
spec:
  podSelector:
    matchLabels:
      role: frontend
  ingress:
  - ports:
    - protocol: TCP
      port: 80
    - protocol: TCP
      port: 443

Accepter les connexions en utilisant des sélecteurs d'espace de noms et de pods :

Pour faire correspondre le trafic réseau en combinant les sélecteurs d'espace de noms et de pods, vous pouvez utiliser un objet NetworkPolicy similaire à ce qui suit :

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-pod-and-namespace-both
spec:
  podSelector:
    matchLabels:
      name: test-pods
  ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            project: project_name
        podSelector:
          matchLabels:
            name: test-pods

Réduisez le nombre de règles de flux OVS en utilisant des espaces de noms pour contenir des groupes de pods qui doivent être isolés.

NetworkPolicy les objets qui sélectionnent un espace de noms entier, en utilisant le site namespaceSelector ou un site vide podSelector, ne génèrent qu'une seule règle de flux OVS correspondant à l'ID de réseau virtuel VXLAN (VNID) de l'espace de noms.

Chaque règle ingress ou egress basée sur les spécifications podSelector ou namespaceSelector génère un nombre de flux OVS proportionnel à number of pods selected by network policy number of pods selected by ingress or egress rule. Il est donc préférable d'utiliser les spécifications podSelector ou namespaceSelector qui permettent de sélectionner autant de pods que nécessaire dans une règle, plutôt que de créer des règles individuelles pour chaque pod.

Par exemple, la politique suivante contient deux règles :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: test-network-policy
spec:
  podSelector: {}
  ingress:
    - from:
       - podSelector:
           matchLabels:
             role: frontend
    - from:
       - podSelector:
           matchLabels:
             role: backend

La politique suivante exprime ces deux règles en une seule :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: test-network-policy
spec:
  podSelector: {}
  ingress:
    - from:
       - podSelector:
           matchExpressions:
             - {key: role, operator: In, values: [frontend, backend]}

La même règle s'applique à la spécification spec.podSelector. Si vous avez les mêmes règles ingress ou egress pour différentes politiques de réseau, il peut être plus efficace de créer une politique de réseau avec une spécification spec.podSelector commune. Par exemple, les deux politiques suivantes ont des règles différentes :

metadata:
 name: policy1
spec:
 podSelector:
   matchLabels:
     role: db
  ingress:
    - from:
       - podSelector:
           matchLabels:
             role: frontend

metadata:
 name: policy2
spec:
 podSelector:
   matchLabels:
     role: client
  ingress:
    - from:
       - podSelector:
           matchLabels:
             role: frontend

La politique de réseau suivante exprime ces deux règles en une seule :

metadata:
 name: policy3
spec:
 podSelector:
   matchExpressions:
     - {key: role, operator: In, values: [db, client]}
  ingress:
    - from:
       - podSelector:
           matchLabels:
             role: frontend

Vous pouvez appliquer cette optimisation lorsque seuls plusieurs sélecteurs sont exprimés comme un seul. Dans les cas où les sélecteurs sont basés sur des étiquettes différentes, il peut être impossible d'appliquer cette optimisation. Dans ce cas, envisagez d'appliquer de nouvelles étiquettes pour l'optimisation de la politique de réseau en particulier.