6.3. La politique de réseau


6.3.1. À propos de la politique de réseau

En tant que développeur, vous pouvez définir des stratégies réseau qui limitent le trafic aux pods dans votre cluster.

6.3.1.1. À propos de la politique de réseau

Par défaut, tous les pods d’un projet sont accessibles à partir d’autres gousses et points de terminaison réseau. Afin d’isoler un ou plusieurs pods dans un projet, vous pouvez créer des objets NetworkPolicy dans ce projet pour indiquer les connexions entrantes autorisées. Les administrateurs de projet peuvent créer et supprimer des objets NetworkPolicy dans leur propre projet.

Lorsqu’une pod est appariée par des sélecteurs dans un ou plusieurs objets NetworkPolicy, la pod n’acceptera que des connexions autorisées par au moins un de ces objets NetworkPolicy. La pod qui n’est pas sélectionnée par aucun objet NetworkPolicy est entièrement accessible.

La politique réseau ne s’applique qu’aux protocoles TCP, UDP, ICMP et SCTP. D’autres protocoles ne sont pas affectés.

Avertissement

La stratégie réseau ne s’applique pas à l’espace de noms du réseau hôte. Les pods avec le réseau hôte activé ne sont pas affectés par les règles de stratégie réseau. Cependant, les pods se connectant aux pods en réseau d’hôte pourraient être affectés par les règles de politique du réseau.

Les stratégies réseau ne peuvent pas bloquer le trafic de l’hôte local ou de leurs nœuds résidents.

L’exemple suivant d’objets NetworkPolicy démontre la prise en charge de différents scénarios:

  • Refuser tout trafic:

    Afin de rendre un projet 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: []
    Copy to Clipboard Toggle word wrap
  • Autoriser uniquement les connexions à partir du service Red Hat OpenShift sur AWS Ingress Controller:

    Afin de faire un projet, n’autorisez que les connexions à partir du service Red Hat OpenShift sur AWS Ingress Controller, 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
    Copy to Clipboard Toggle word wrap
  • Accepter uniquement les connexions des pods au sein d’un projet:

    Important

    Afin d’autoriser les connexions entrantes à partir des pods hostNetwork dans le même espace de noms, vous devez appliquer la politique d’autorisation de l’hôte avec la politique d’autorisation-même-namespace.

    Afin de faire accepter les connexions d’autres pods dans le même projet, mais rejeter toutes les autres connexions de pods dans d’autres projets, ajouter l’objet NetworkPolicy suivant:

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: allow-same-namespace
    spec:
      podSelector: {}
      ingress:
      - from:
        - podSelector: {}
    Copy to Clipboard Toggle word wrap
  • Autoriser uniquement le trafic HTTP et HTTPS basé sur les étiquettes de pod:

    Afin d’activer uniquement l’accès HTTP et HTTPS aux pods avec une étiquette spécifique (rôle=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
    Copy to Clipboard Toggle word wrap
  • Accepter les connexions en utilisant à la fois namespace et pod sélecteurs:

    Afin de faire correspondre le trafic réseau en combinant l’espace de noms et les sélecteurs de pod, 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
    Copy to Clipboard Toggle word wrap

Les objets NetworkPolicy sont additifs, ce qui signifie que vous pouvez combiner plusieurs objets NetworkPolicy pour répondre à des exigences réseau complexes.

À titre d’exemple, pour les objets NetworkPolicy définis dans les échantillons précédents, vous pouvez définir à la fois des stratégies d’autorisation-même-namespace et d’autorisation-http-and-https au sein d’un même projet. Ainsi, permettant aux pods avec le label role=frontend, d’accepter toute connexion autorisée par chaque politique. Autrement dit, les connexions sur n’importe quel port à partir de pods dans le même espace de noms, et les connexions sur les ports 80 et 443 à partir de pods dans n’importe quel espace de noms.

Utilisez la NetworkPolicy suivante pour autoriser le trafic externe quelle que soit la configuration du routeur:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-router
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/ingress: ""
1

  podSelector: {}
  policyTypes:
  - Ingress
Copy to Clipboard Toggle word wrap
1
le label policy-group.network.openshift.io/ingress:" prend en charge OVN-Kubernetes.

Ajoutez l’objet Permis-from-hostnetwork NetworkPolicy suivant pour diriger le trafic à partir des pods réseau hôte.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-hostnetwork
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/host-network: ""
  podSelector: {}
  policyTypes:
  - Ingress
Copy to Clipboard Toggle word wrap

Lors de la conception de votre politique de réseau, consultez les lignes directrices suivantes:

  • Dans le cas des stratégies réseau avec la même spécification spec.podSelector, il est plus efficace d’utiliser une stratégie réseau avec plusieurs règles d’entrée ou de sortie, que plusieurs stratégies réseau avec des sous-ensembles de règles d’entrée ou de sortie.
  • Chaque règle d’entrée ou de sortie basée sur la spécification podSelector ou namespaceSelector génère le nombre de flux OVS proportionnels au nombre de pods sélectionnés par stratégie réseau + nombre de pods sélectionnés par la règle d’entrée ou de sortie. Il est donc préférable d’utiliser la spécification podSelector ou namespaceSelector qui peut sélectionner autant de pods que vous en avez besoin en une seule règle, au lieu de créer des règles individuelles pour chaque pod.

    À titre d’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
    Copy to Clipboard Toggle word wrap

    La politique suivante exprime ces deux mêmes règles qu’une:

    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]}
    Copy to Clipboard Toggle word wrap

    La même ligne directrice s’applique à la spécification spec.podSelector. Lorsque vous avez les mêmes règles d’entrée ou de sortie pour différentes politiques de réseau, il pourrait être plus efficace de créer une politique réseau avec une spécification spec.podSelector commune. À titre d’exemple, les deux politiques suivantes ont des règles différentes:

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: policy1
    spec:
      podSelector:
        matchLabels:
          role: db
      ingress:
      - from:
        - podSelector:
            matchLabels:
              role: frontend
    ---
    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: policy2
    spec:
      podSelector:
        matchLabels:
          role: client
      ingress:
      - from:
        - podSelector:
            matchLabels:
              role: frontend
    Copy to Clipboard Toggle word wrap

    La politique de réseau suivante exprime ces deux mêmes règles qu’une:

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: policy3
    spec:
      podSelector:
        matchExpressions:
        - {key: role, operator: In, values: [db, client]}
      ingress:
      - from:
        - podSelector:
            matchLabels:
              role: frontend
    Copy to Clipboard Toggle word wrap

    Cette optimisation peut être appliquée lorsque seulement plusieurs sélecteurs sont exprimés en un seul. Dans les cas où les sélecteurs sont basés sur différentes étiquettes, il peut être impossible d’appliquer cette optimisation. Dans ces cas, envisagez d’appliquer de nouvelles étiquettes pour l’optimisation des politiques réseau spécifiquement.

6.3.1.3. Les prochaines étapes

6.3.2. Créer une politique de réseau

En tant qu’utilisateur avec le rôle d’administrateur, vous pouvez créer une stratégie réseau pour un espace de noms.

6.3.2.1. Exemple d’objet NetworkPolicy

Ce qui suit annote un exemple d’objet NetworkPolicy:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107 
1

spec:
  podSelector: 
2

    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector: 
3

        matchLabels:
          app: app
    ports: 
4

    - protocol: TCP
      port: 27017
Copy to Clipboard Toggle word wrap
1
Le nom de l’objet NetworkPolicy.
2
C) un sélecteur qui décrit les pods auxquels la politique s’applique. L’objet de stratégie ne peut sélectionner que des pods dans le projet qui définit l’objet NetworkPolicy.
3
D’un sélecteur qui correspond aux pods à partir desquels l’objet de stratégie permet le trafic d’entrée. Le sélecteur correspond aux pods dans le même espace de noms que NetworkPolicy.
4
Liste d’un ou de plusieurs ports de destination sur lesquels accepter le trafic.

Afin de définir des règles granulaires décrivant le trafic réseau d’entrée ou de sortie autorisé pour les espaces de noms de votre cluster, vous pouvez créer une stratégie réseau.

Note

Lorsque vous vous connectez avec un utilisateur avec le rôle cluster-admin, vous pouvez créer une stratégie réseau dans n’importe quel espace de noms du cluster.

Conditions préalables

  • Le cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tels que le plugin réseau OVN-Kubernetes, avec mode: NetworkPolicy set.
  • Installation de l’OpenShift CLI (oc).
  • Il est connecté au cluster avec un utilisateur avec des privilèges d’administrateur.
  • C’est vous qui travaillez dans l’espace de noms auquel s’applique la stratégie réseau.

Procédure

  1. Créer une règle de politique:

    1. Créer un fichier <policy_name>.yaml:

      $ touch <policy_name>.yaml
      Copy to Clipboard Toggle word wrap

      là où:

      &lt;policy_name&gt;
      Indique le nom du fichier de stratégie réseau.
    2. Définissez une stratégie réseau dans le fichier que vous venez de créer, comme dans les exemples suivants:

      Dénier l’entrée de tous les pods dans tous les espaces de noms

      Il s’agit d’une politique fondamentale, bloquant tout réseau interpod autre que le trafic interpod autorisé par la configuration d’autres stratégies réseau.

      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: deny-by-default
      spec:
        podSelector: {}
        policyTypes:
        - Ingress
        ingress: []
      Copy to Clipboard Toggle word wrap

      Autoriser l’entrée de tous les pods dans le même espace de noms

      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: allow-same-namespace
      spec:
        podSelector:
        ingress:
        - from:
          - podSelector: {}
      Copy to Clipboard Toggle word wrap

      Autoriser le trafic d’entrée vers un pod à partir d’un espace de noms particulier

      Cette politique permet au trafic de pods étiquetés pod-a à partir de pods fonctionnant dans namespace-y.

      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: allow-traffic-pod
      spec:
        podSelector:
         matchLabels:
            pod: pod-a
        policyTypes:
        - Ingress
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                 kubernetes.io/metadata.name: namespace-y
      Copy to Clipboard Toggle word wrap
  2. Afin de créer l’objet de stratégie réseau, entrez la commande suivante:

    $ oc apply -f <policy_name>.yaml -n <namespace>
    Copy to Clipboard Toggle word wrap

    là où:

    &lt;policy_name&gt;
    Indique le nom du fichier de stratégie réseau.
    &lt;namespace&gt;
    Facultatif : Spécifie l’espace de noms si l’objet est défini dans un espace de noms différent de celui de l’espace de noms actuel.

    Exemple de sortie

    networkpolicy.networking.k8s.io/deny-by-default created
    Copy to Clipboard Toggle word wrap

Note

Lorsque vous vous connectez à la console Web avec des privilèges cluster-admin, vous avez le choix de créer une stratégie réseau dans n’importe quel espace de noms du cluster directement dans YAML ou à partir d’un formulaire dans la console Web.

6.3.2.3. Création d’une stratégie de réseau par défaut

Il s’agit d’une politique fondamentale, bloquant tout réseau interpod autre que le trafic réseau autorisé par la configuration d’autres stratégies réseau déployées. Cette procédure applique une politique de refus par défaut.

Note

Lorsque vous vous connectez avec un utilisateur avec le rôle cluster-admin, vous pouvez créer une stratégie réseau dans n’importe quel espace de noms du cluster.

Conditions préalables

  • Le cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tels que le plugin réseau OVN-Kubernetes, avec mode: NetworkPolicy set.
  • Installation de l’OpenShift CLI (oc).
  • Il est connecté au cluster avec un utilisateur avec des privilèges d’administrateur.
  • C’est vous qui travaillez dans l’espace de noms auquel s’applique la stratégie réseau.

Procédure

  1. Créez le YAML suivant qui définit une politique de déni par défaut pour refuser l’entrée de tous les pods dans tous les espaces de noms. Enregistrez le YAML dans le fichier deny-by-default.yaml:

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: deny-by-default
      namespace: default 
    1
    
    spec:
      podSelector: {} 
    2
    
      ingress: [] 
    3
    Copy to Clipboard Toggle word wrap
    1
    namespace: par défaut déploie cette stratégie dans l’espace de noms par défaut.
    2
    le podSelector: est vide, cela signifie qu’il correspond à tous les gousses. La politique s’applique donc à tous les pods dans l’espace de noms par défaut.
    3
    Il n’y a pas de règles d’entrée spécifiées. Cela provoque la chute du trafic entrant vers toutes les gousses.
  2. Appliquer la politique en entrant la commande suivante:

    $ oc apply -f deny-by-default.yaml
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    networkpolicy.networking.k8s.io/deny-by-default created
    Copy to Clipboard Toggle word wrap

Avec la stratégie de refus par défaut en place, vous pouvez procéder à la configuration d’une stratégie qui permet le trafic des clients externes vers un pod avec l’app=web d’étiquette.

Note

Lorsque vous vous connectez avec un utilisateur avec le rôle cluster-admin, vous pouvez créer une stratégie réseau dans n’importe quel espace de noms du cluster.

Cette procédure permet de configurer une politique qui permet au service externe de l’Internet public directement ou en utilisant un Balanceur de charge d’accéder au pod. Le trafic n’est autorisé qu’à un pod avec l’étiquette app=web.

Conditions préalables

  • Le cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tels que le plugin réseau OVN-Kubernetes, avec mode: NetworkPolicy set.
  • Installation de l’OpenShift CLI (oc).
  • Il est connecté au cluster avec un utilisateur avec des privilèges d’administrateur.
  • C’est vous qui travaillez dans l’espace de noms auquel s’applique la stratégie réseau.

Procédure

  1. Créez une politique qui permet le trafic depuis l’Internet public directement ou en utilisant un balanceur de charge pour accéder au pod. Enregistrez le YAML dans le fichier web-allow-external.yaml:

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: web-allow-external
      namespace: default
    spec:
      policyTypes:
      - Ingress
      podSelector:
        matchLabels:
          app: web
      ingress:
        - {}
    Copy to Clipboard Toggle word wrap
  2. Appliquer la politique en entrant la commande suivante:

    $ oc apply -f web-allow-external.yaml
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    networkpolicy.networking.k8s.io/web-allow-external created
    Copy to Clipboard Toggle word wrap

    Cette politique permet le trafic à partir de toutes les ressources, y compris le trafic externe comme illustré dans le diagramme suivant:

Note

Lorsque vous vous connectez avec un utilisateur avec le rôle cluster-admin, vous pouvez créer une stratégie réseau dans n’importe quel espace de noms du cluster.

Cette procédure permet de configurer une stratégie qui permet le trafic de tous les pods dans tous les espaces de noms à une application particulière.

Conditions préalables

  • Le cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tels que le plugin réseau OVN-Kubernetes, avec mode: NetworkPolicy set.
  • Installation de l’OpenShift CLI (oc).
  • Il est connecté au cluster avec un utilisateur avec des privilèges d’administrateur.
  • C’est vous qui travaillez dans l’espace de noms auquel s’applique la stratégie réseau.

Procédure

  1. Créez une stratégie qui permet le trafic de tous les pods dans tous les espaces de noms vers une application particulière. Enregistrez le YAML dans le fichier web-allow-all-namespaces.yaml:

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: web-allow-all-namespaces
      namespace: default
    spec:
      podSelector:
        matchLabels:
          app: web 
    1
    
      policyTypes:
      - Ingress
      ingress:
      - from:
        - namespaceSelector: {} 
    2
    Copy to Clipboard Toggle word wrap
    1
    Applique la stratégie uniquement aux pods app:web dans l’espace de noms par défaut.
    2
    Sélectionne tous les pods dans tous les espaces de noms.
    Note

    Par défaut, si vous omet de spécifier un namespaceSelector, il ne sélectionne pas d’espaces de noms, ce qui signifie que la stratégie autorise le trafic uniquement à partir de l’espace de noms vers lequel la stratégie réseau est déployée.

  2. Appliquer la politique en entrant la commande suivante:

    $ oc apply -f web-allow-all-namespaces.yaml
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    networkpolicy.networking.k8s.io/web-allow-all-namespaces created
    Copy to Clipboard Toggle word wrap

La vérification

  1. Démarrez un service Web dans l’espace de noms par défaut en entrant la commande suivante:

    $ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
    Copy to Clipboard Toggle word wrap
  2. Exécutez la commande suivante pour déployer une image alpine dans l’espace de noms secondaire et démarrer un shell:

    $ oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh
    Copy to Clipboard Toggle word wrap
  3. Exécutez la commande suivante dans le shell et observez que la requête est autorisée:

    # wget -qO- --timeout=2 http://web.default
    Copy to Clipboard Toggle word wrap

    A) Produit attendu

    <!DOCTYPE html>
    <html>
    <head>
    <title>Welcome to nginx!</title>
    <style>
    html { color-scheme: light dark; }
    body { width: 35em; margin: 0 auto;
    font-family: Tahoma, Verdana, Arial, sans-serif; }
    </style>
    </head>
    <body>
    <h1>Welcome to nginx!</h1>
    <p>If you see this page, the nginx web server is successfully installed and
    working. Further configuration is required.</p>
    
    <p>For online documentation and support please refer to
    <a href="http://nginx.org/">nginx.org</a>.<br/>
    Commercial support is available at
    <a href="http://nginx.com/">nginx.com</a>.</p>
    
    <p><em>Thank you for using nginx.</em></p>
    </body>
    </html>
    Copy to Clipboard Toggle word wrap

Note

Lorsque vous vous connectez avec un utilisateur avec le rôle cluster-admin, vous pouvez créer une stratégie réseau dans n’importe quel espace de noms du cluster.

Cette procédure permet de configurer une stratégie qui permet le trafic vers un pod avec l’étiquette app=web à partir d’un espace de noms particulier. Il se peut que vous vouliez faire ceci pour:

  • Limitez le trafic à une base de données de production uniquement aux espaces de noms où des charges de travail de production sont déployées.
  • Activer les outils de surveillance déployés dans un espace de noms particulier pour gratter des métriques à partir de l’espace de noms actuel.

Conditions préalables

  • Le cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tels que le plugin réseau OVN-Kubernetes, avec mode: NetworkPolicy set.
  • Installation de l’OpenShift CLI (oc).
  • Il est connecté au cluster avec un utilisateur avec des privilèges d’administrateur.
  • C’est vous qui travaillez dans l’espace de noms auquel s’applique la stratégie réseau.

Procédure

  1. Créez une stratégie qui permet le trafic de tous les pods dans un espace de noms particulier avec un but d’étiquette=production. Enregistrez le YAML dans le fichier web-allow-prod.yaml:

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: web-allow-prod
      namespace: default
    spec:
      podSelector:
        matchLabels:
          app: web 
    1
    
      policyTypes:
      - Ingress
      ingress:
      - from:
        - namespaceSelector:
            matchLabels:
              purpose: production 
    2
    Copy to Clipboard Toggle word wrap
    1
    Applique la stratégie uniquement aux pods app:web dans l’espace de noms par défaut.
    2
    Limite le trafic aux seuls pods dans les espaces de noms qui ont le but de l’étiquette=production.
  2. Appliquer la politique en entrant la commande suivante:

    $ oc apply -f web-allow-prod.yaml
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    networkpolicy.networking.k8s.io/web-allow-prod created
    Copy to Clipboard Toggle word wrap

La vérification

  1. Démarrez un service Web dans l’espace de noms par défaut en entrant la commande suivante:

    $ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
    Copy to Clipboard Toggle word wrap
  2. Exécutez la commande suivante pour créer l’espace de noms prod:

    $ oc create namespace prod
    Copy to Clipboard Toggle word wrap
  3. Exécutez la commande suivante pour étiqueter l’espace de noms prod:

    $ oc label namespace/prod purpose=production
    Copy to Clipboard Toggle word wrap
  4. Exécutez la commande suivante pour créer l’espace de noms dev:

    $ oc create namespace dev
    Copy to Clipboard Toggle word wrap
  5. Exécutez la commande suivante pour étiqueter l’espace de noms dev:

    $ oc label namespace/dev purpose=testing
    Copy to Clipboard Toggle word wrap
  6. Exécutez la commande suivante pour déployer une image alpine dans l’espace de noms de dev et démarrer un shell:

    $ oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh
    Copy to Clipboard Toggle word wrap
  7. Exécutez la commande suivante dans le shell et observez que la requête est bloquée:

    # wget -qO- --timeout=2 http://web.default
    Copy to Clipboard Toggle word wrap

    A) Produit attendu

    wget: download timed out
    Copy to Clipboard Toggle word wrap

  8. Exécutez la commande suivante pour déployer une image alpine dans l’espace de noms prod et démarrer un shell:

    $ oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- sh
    Copy to Clipboard Toggle word wrap
  9. Exécutez la commande suivante dans le shell et observez que la requête est autorisée:

    # wget -qO- --timeout=2 http://web.default
    Copy to Clipboard Toggle word wrap

    A) Produit attendu

    <!DOCTYPE html>
    <html>
    <head>
    <title>Welcome to nginx!</title>
    <style>
    html { color-scheme: light dark; }
    body { width: 35em; margin: 0 auto;
    font-family: Tahoma, Verdana, Arial, sans-serif; }
    </style>
    </head>
    <body>
    <h1>Welcome to nginx!</h1>
    <p>If you see this page, the nginx web server is successfully installed and
    working. Further configuration is required.</p>
    
    <p>For online documentation and support please refer to
    <a href="http://nginx.org/">nginx.org</a>.<br/>
    Commercial support is available at
    <a href="http://nginx.com/">nginx.com</a>.</p>
    
    <p><em>Thank you for using nginx.</em></p>
    </body>
    </html>
    Copy to Clipboard Toggle word wrap

Afin de définir des règles granulaires décrivant le trafic réseau d’entrée ou de sortie autorisé pour les espaces de noms de votre cluster, vous pouvez créer une stratégie réseau.

Conditions préalables

  • Connectez-vous à OpenShift Cluster Manager.
  • Création d’un Red Hat OpenShift Service sur AWS cluster.
  • Configuration d’un fournisseur d’identité pour votre cluster.
  • Ajout de votre compte utilisateur au fournisseur d’identité configuré.
  • Dans le cadre de votre Red Hat OpenShift Service, vous avez créé un projet sur le cluster AWS.

Procédure

  1. À partir d’OpenShift Cluster Manager, cliquez sur le cluster auquel vous souhaitez accéder.
  2. Cliquez sur Ouvrir la console pour accéder à la console Web OpenShift.
  3. Cliquez sur votre fournisseur d’identité et fournissez vos informations d’identification pour vous connecter au cluster.
  4. Du point de vue administrateur, sous Networking, cliquez sur NetworkPolicies.
  5. Cliquez sur Créer NetworkPolicy.
  6. Indiquez un nom pour la politique dans le champ Nom de la politique.
  7. Facultatif: Vous pouvez fournir l’étiquette et le sélecteur pour un pod spécifique si cette politique ne s’applique qu’à un ou plusieurs gousses spécifiques. Dans le cas où vous ne sélectionnez pas un pod spécifique, cette politique s’appliquera à tous les pods du cluster.
  8. Facultatif: Vous pouvez bloquer tous les trafics d’entrée et de sortie en utilisant le Deny tous les trafics entrants ou Deny toutes les cases à cocher du trafic sortant.
  9. En outre, vous pouvez ajouter n’importe quelle combinaison de règles d’entrée et de sortie, vous permettant de spécifier le port, l’espace de noms ou les blocs IP que vous souhaitez approuver.
  10. Ajoutez des règles d’entrée à votre politique:

    1. Cliquez sur Ajouter une règle d’entrée pour configurer une nouvelle règle. Cette action crée une nouvelle ligne de règles Ingress avec un menu déroulant Ajouter la source autorisée qui vous permet de spécifier la façon dont vous souhaitez limiter le trafic entrant. Le menu déroulant offre trois options pour limiter votre trafic d’entrée:

      • Autoriser les pods du même espace de noms limite le trafic aux pods dans le même espace de noms. Dans un espace de noms, vous pouvez spécifier les pods, mais laisser cette option en blanc permet tout le trafic à partir des pods dans l’espace de noms.
      • Autoriser les pods de l’intérieur du cluster limite le trafic à des pods dans le même cluster que la politique. Il est possible de spécifier les espaces de noms et les pods à partir desquels vous souhaitez autoriser le trafic entrant. Laisser cette option vide permet le trafic entrant à partir de tous les espaces de noms et les pods dans ce cluster.
      • Autoriser les pairs par le blocage IP limite le trafic à partir d’un bloc IP de routage interdomain (CIDR) spécifié. Il est possible de bloquer certaines adresses IP avec l’option exception. Laisser le champ CIDR vide permet tout le trafic entrant de toutes les sources externes.
    2. Il est possible de limiter tout votre trafic entrant à un port. Dans le cas où vous n’y ajoutez pas de ports, tous les ports sont accessibles au trafic.
  11. Ajoutez des règles de sortie à votre politique de réseau:

    1. Cliquez sur Ajouter une règle de sortie pour configurer une nouvelle règle. Cette action crée une nouvelle ligne de règles Egress avec un menu déroulant Ajouter la destination autorisée* qui vous permet de spécifier la façon dont vous souhaitez limiter le trafic sortant. Le menu déroulant offre trois options pour limiter votre trafic de sortie:

      • Autoriser les pods du même espace de noms limite le trafic sortant aux pods dans le même espace de noms. Dans un espace de noms, vous pouvez spécifier les pods, mais laisser cette option en blanc permet tout le trafic à partir des pods dans l’espace de noms.
      • Autoriser les pods de l’intérieur du cluster limite le trafic à des pods dans le même cluster que la politique. Il est possible de spécifier les espaces de noms et les pods à partir desquels vous souhaitez autoriser le trafic sortant. Laisser cette option vide permet le trafic sortant de tous les espaces de noms et pods au sein de ce cluster.
      • Autoriser les pairs par le blocage IP limite le trafic à partir d’un bloc IP CIDR spécifié. Il est possible de bloquer certaines adresses IP avec l’option exception. Laisser le champ CIDR vide permet tout le trafic sortant de toutes les sources externes.
    2. Il est possible de limiter tout votre trafic sortant à un port. Dans le cas où vous n’y ajoutez pas de ports, tous les ports sont accessibles au trafic.

6.3.3. Affichage d’une politique de réseau

En tant qu’utilisateur avec le rôle d’administrateur, vous pouvez afficher une stratégie réseau pour un espace de noms.

6.3.3.1. Exemple d’objet NetworkPolicy

Ce qui suit annote un exemple d’objet NetworkPolicy:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107 
1

spec:
  podSelector: 
2

    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector: 
3

        matchLabels:
          app: app
    ports: 
4

    - protocol: TCP
      port: 27017
Copy to Clipboard Toggle word wrap
1
Le nom de l’objet NetworkPolicy.
2
C) un sélecteur qui décrit les pods auxquels la politique s’applique. L’objet de stratégie ne peut sélectionner que des pods dans le projet qui définit l’objet NetworkPolicy.
3
D’un sélecteur qui correspond aux pods à partir desquels l’objet de stratégie permet le trafic d’entrée. Le sélecteur correspond aux pods dans le même espace de noms que NetworkPolicy.
4
Liste d’un ou de plusieurs ports de destination sur lesquels accepter le trafic.

Il est possible d’examiner les stratégies réseau dans un espace de noms.

Note

Lorsque vous vous connectez avec un utilisateur avec le rôle cluster-admin, vous pouvez afficher n’importe quelle stratégie réseau dans le cluster.

Conditions préalables

  • Installation de l’OpenShift CLI (oc).
  • Il est connecté au cluster avec un utilisateur avec des privilèges d’administrateur.
  • Dans l’espace de noms où existe la stratégie réseau, vous travaillez.

Procédure

  • Liste des stratégies réseau dans un espace de noms:

    • Afin d’afficher les objets de stratégie réseau définis dans un espace de noms, entrez la commande suivante:

      $ oc get networkpolicy
      Copy to Clipboard Toggle word wrap
    • Facultatif: Pour examiner une stratégie réseau spécifique, entrez la commande suivante:

      $ oc describe networkpolicy <policy_name> -n <namespace>
      Copy to Clipboard Toggle word wrap

      là où:

      &lt;policy_name&gt;
      Indique le nom de la politique de réseau à inspecter.
      &lt;namespace&gt;
      Facultatif : Spécifie l’espace de noms si l’objet est défini dans un espace de noms différent de celui de l’espace de noms actuel.

      À titre d’exemple:

      $ oc describe networkpolicy allow-same-namespace
      Copy to Clipboard Toggle word wrap

      La sortie pour oc décrit la commande

      Name:         allow-same-namespace
      Namespace:    ns1
      Created on:   2021-05-24 22:28:56 -0400 EDT
      Labels:       <none>
      Annotations:  <none>
      Spec:
        PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
        Allowing ingress traffic:
          To Port: <any> (traffic allowed to all ports)
          From:
            PodSelector: <none>
        Not affecting egress traffic
        Policy Types: Ingress
      Copy to Clipboard Toggle word wrap

Note

Lorsque vous vous connectez à la console Web avec des privilèges d’administration de cluster, vous avez le choix de visualiser une stratégie réseau dans n’importe quel espace de noms du cluster directement dans YAML ou à partir d’un formulaire dans la console Web.

Consultez les détails de configuration de votre stratégie réseau dans Red Hat OpenShift Cluster Manager.

Conditions préalables

  • Connectez-vous à OpenShift Cluster Manager.
  • Création d’un Red Hat OpenShift Service sur AWS cluster.
  • Configuration d’un fournisseur d’identité pour votre cluster.
  • Ajout de votre compte utilisateur au fournisseur d’identité configuré.
  • C’est vous qui avez créé une stratégie de réseau.

Procédure

  1. Du point de vue administrateur dans la console Web OpenShift Cluster Manager, sous Networking, cliquez sur NetworkPolicies.
  2. Choisissez la politique de réseau souhaitée à afficher.
  3. Dans la page Détails de la stratégie réseau, vous pouvez consulter toutes les règles d’entrée et de sortie associées.
  4. Choisissez YAML sur les détails de la stratégie réseau pour afficher la configuration de la stratégie au format YAML.

    Note

    Il est possible de consulter uniquement les détails de ces politiques. Il est impossible d’éditer ces politiques.

6.3.4. Édition d’une politique de réseau

En tant qu’utilisateur avec le rôle d’administrateur, vous pouvez modifier une stratégie réseau existante pour un espace de noms.

6.3.4.1. Édition d’une politique de réseau

Il est possible d’éditer une stratégie réseau dans un espace de noms.

Note

Lorsque vous vous connectez avec un utilisateur avec le rôle cluster-admin, vous pouvez modifier une stratégie réseau dans n’importe quel espace de noms du cluster.

Conditions préalables

  • Le cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tels que le plugin réseau OVN-Kubernetes, avec mode: NetworkPolicy set.
  • Installation de l’OpenShift CLI (oc).
  • Il est connecté au cluster avec un utilisateur avec des privilèges d’administrateur.
  • Dans l’espace de noms où existe la stratégie réseau, vous travaillez.

Procédure

  1. Facultatif: Pour énumérer les objets de stratégie réseau dans un espace de noms, entrez la commande suivante:

    $ oc get networkpolicy
    Copy to Clipboard Toggle word wrap

    là où:

    &lt;namespace&gt;
    Facultatif : Spécifie l’espace de noms si l’objet est défini dans un espace de noms différent de celui de l’espace de noms actuel.
  2. Editez l’objet de stratégie réseau.

    • Lorsque vous enregistrez la définition de stratégie réseau dans un fichier, modifiez le fichier et apportez les modifications nécessaires, puis entrez la commande suivante.

      $ oc apply -n <namespace> -f <policy_file>.yaml
      Copy to Clipboard Toggle word wrap

      là où:

      &lt;namespace&gt;
      Facultatif : Spécifie l’espace de noms si l’objet est défini dans un espace de noms différent de celui de l’espace de noms actuel.
      &lt;policy_file&gt;
      Indique le nom du fichier contenant la stratégie réseau.
    • Lorsque vous devez mettre à jour l’objet de stratégie réseau directement, entrez la commande suivante:

      $ oc edit networkpolicy <policy_name> -n <namespace>
      Copy to Clipboard Toggle word wrap

      là où:

      &lt;policy_name&gt;
      Indique le nom de la stratégie réseau.
      &lt;namespace&gt;
      Facultatif : Spécifie l’espace de noms si l’objet est défini dans un espace de noms différent de celui de l’espace de noms actuel.
  3. Confirmez que l’objet de stratégie réseau est mis à jour.

    $ oc describe networkpolicy <policy_name> -n <namespace>
    Copy to Clipboard Toggle word wrap

    là où:

    &lt;policy_name&gt;
    Indique le nom de la stratégie réseau.
    &lt;namespace&gt;
    Facultatif : Spécifie l’espace de noms si l’objet est défini dans un espace de noms différent de celui de l’espace de noms actuel.
Note

Lorsque vous vous connectez à la console Web avec des privilèges cluster-admin, vous avez le choix d’éditer une stratégie réseau dans n’importe quel espace de noms du cluster directement dans YAML ou à partir de la stratégie de la console Web via le menu Actions.

6.3.4.2. Exemple d’objet NetworkPolicy

Ce qui suit annote un exemple d’objet NetworkPolicy:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107 
1

spec:
  podSelector: 
2

    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector: 
3

        matchLabels:
          app: app
    ports: 
4

    - protocol: TCP
      port: 27017
Copy to Clipboard Toggle word wrap
1
Le nom de l’objet NetworkPolicy.
2
C) un sélecteur qui décrit les pods auxquels la politique s’applique. L’objet de stratégie ne peut sélectionner que des pods dans le projet qui définit l’objet NetworkPolicy.
3
D’un sélecteur qui correspond aux pods à partir desquels l’objet de stratégie permet le trafic d’entrée. Le sélecteur correspond aux pods dans le même espace de noms que NetworkPolicy.
4
Liste d’un ou de plusieurs ports de destination sur lesquels accepter le trafic.

6.3.5. La suppression d’une politique de réseau

En tant qu’utilisateur avec le rôle d’administrateur, vous pouvez supprimer une stratégie réseau d’un espace de noms.

Il est possible de supprimer une stratégie réseau dans un espace de noms.

Note

Lorsque vous vous connectez avec un utilisateur avec le rôle cluster-admin, vous pouvez supprimer n’importe quelle stratégie réseau dans le cluster.

Conditions préalables

  • Le cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tels que le plugin réseau OVN-Kubernetes, avec mode: NetworkPolicy set.
  • Installation de l’OpenShift CLI (oc).
  • Il est connecté au cluster avec un utilisateur avec des privilèges d’administrateur.
  • Dans l’espace de noms où existe la stratégie réseau, vous travaillez.

Procédure

  • Afin de supprimer un objet de stratégie réseau, entrez la commande suivante:

    $ oc delete networkpolicy <policy_name> -n <namespace>
    Copy to Clipboard Toggle word wrap

    là où:

    &lt;policy_name&gt;
    Indique le nom de la stratégie réseau.
    &lt;namespace&gt;
    Facultatif : Spécifie l’espace de noms si l’objet est défini dans un espace de noms différent de celui de l’espace de noms actuel.

    Exemple de sortie

    networkpolicy.networking.k8s.io/default-deny deleted
    Copy to Clipboard Toggle word wrap

Note

Lorsque vous vous connectez à la console Web avec des privilèges cluster-admin, vous avez le choix de supprimer une stratégie réseau dans n’importe quel espace de noms du cluster directement dans YAML ou à partir de la stratégie de la console Web via le menu Actions.

Il est possible de supprimer une stratégie réseau dans un espace de noms.

Conditions préalables

  • Connectez-vous à OpenShift Cluster Manager.
  • Création d’un Red Hat OpenShift Service sur AWS cluster.
  • Configuration d’un fournisseur d’identité pour votre cluster.
  • Ajout de votre compte utilisateur au fournisseur d’identité configuré.

Procédure

  1. Du point de vue administrateur dans la console Web OpenShift Cluster Manager, sous Networking, cliquez sur NetworkPolicies.
  2. Employez l’une des méthodes suivantes pour supprimer votre politique de réseau:

    • Effacer la politique du tableau des politiques de réseau:

      1. Dans la table Politiques réseau, sélectionnez le menu de pile de la ligne de la stratégie réseau que vous souhaitez supprimer, puis cliquez sur Supprimer NetworkPolicy.
    • Supprimez la stratégie à l’aide du menu déroulant Actions des détails de la stratégie réseau:

      1. Cliquez sur Actions menu déroulant pour votre stratégie de réseau.
      2. Choisissez Supprimer NetworkPolicy dans le menu.

En tant qu’administrateur de cluster, vous pouvez modifier le nouveau modèle de projet pour inclure automatiquement les stratégies réseau lorsque vous créez un nouveau projet. Lorsque vous n’avez pas encore de modèle personnalisé pour de nouveaux projets, vous devez d’abord en créer un.

6.3.6.1. La modification du modèle pour les nouveaux projets

En tant qu’administrateur de cluster, vous pouvez modifier le modèle de projet par défaut afin que de nouveaux projets soient créés en utilisant vos exigences personnalisées.

Créer votre propre modèle de projet personnalisé:

Conditions préalables

  • Grâce à un compte doté d’autorisations d’administration dédiées, vous avez accès à un service Red Hat OpenShift sur AWS.

Procédure

  1. Connectez-vous en tant qu’utilisateur avec des privilèges cluster-admin.
  2. Générer le modèle de projet par défaut:

    $ oc adm create-bootstrap-project-template -o yaml > template.yaml
    Copy to Clipboard Toggle word wrap
  3. Créez un éditeur de texte pour modifier le fichier template.yaml généré en ajoutant des objets ou en modifiant des objets existants.
  4. Le modèle de projet doit être créé dans l’espace de noms openshift-config. Chargez votre modèle modifié:

    $ oc create -f template.yaml -n openshift-config
    Copy to Clipboard Toggle word wrap
  5. Éditez la ressource de configuration du projet à l’aide de la console Web ou du CLI.

    • En utilisant la console web:

      1. Accédez à la page Administration Paramètres du cluster.
      2. Cliquez sur Configuration pour afficher toutes les ressources de configuration.
      3. Cherchez l’entrée pour Projet et cliquez sur Modifier YAML.
    • En utilisant le CLI:

      1. Editez la ressource project.config.openshift.io/cluster:

        $ oc edit project.config.openshift.io/cluster
        Copy to Clipboard Toggle word wrap
  6. Actualisez la section Spécifications pour inclure les paramètres projectRequestTemplate et nom, et définissez le nom de votre modèle de projet téléchargé. Le nom par défaut est project-request.

    Configuration du projet ressource avec modèle de projet personnalisé

    apiVersion: config.openshift.io/v1
    kind: Project
    metadata:
    # ...
    spec:
      projectRequestTemplate:
        name: <template_name>
    # ...
    Copy to Clipboard Toggle word wrap

  7. Après avoir enregistré vos modifications, créez un nouveau projet pour vérifier que vos modifications ont été appliquées avec succès.

En tant qu’administrateur de cluster, vous pouvez ajouter des stratégies réseau au modèle par défaut pour les nouveaux projets. Le service Red Hat OpenShift sur AWS créera automatiquement tous les objets NetworkPolicy spécifiés dans le modèle du projet.

Conditions préalables

  • Le cluster utilise un plugin réseau CNI par défaut qui prend en charge les objets NetworkPolicy, tels que les OVN-Kubernetes.
  • Installation de l’OpenShift CLI (oc).
  • Connectez-vous au cluster avec un utilisateur avec des privilèges cluster-admin.
  • Il faut avoir créé un modèle de projet personnalisé par défaut pour de nouveaux projets.

Procédure

  1. Éditez le modèle par défaut pour un nouveau projet en exécutant la commande suivante:

    $ oc edit template <project_template> -n openshift-config
    Copy to Clipboard Toggle word wrap

    &lt;project_template&gt; par le nom du modèle par défaut que vous avez configuré pour votre cluster. Le nom de modèle par défaut est project-request.

  2. Dans le modèle, ajoutez chaque objet NetworkPolicy en tant qu’élément au paramètre objets. Le paramètre objets accepte une collection d’un ou plusieurs objets.

    Dans l’exemple suivant, la collection de paramètres d’objets comprend plusieurs objets NetworkPolicy.

    objects:
    - apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-same-namespace
      spec:
        podSelector: {}
        ingress:
        - from:
          - podSelector: {}
    - 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
    - apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-kube-apiserver-operator
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                kubernetes.io/metadata.name: openshift-kube-apiserver-operator
            podSelector:
              matchLabels:
                app: kube-apiserver-operator
        policyTypes:
        - Ingress
    ...
    Copy to Clipboard Toggle word wrap
  3. Facultatif: Créez un nouveau projet pour confirmer que vos objets de stratégie réseau sont créés avec succès en exécutant les commandes suivantes:

    1. Créer un nouveau projet:

      $ oc new-project <project> 
      1
      Copy to Clipboard Toggle word wrap
      1
      &lt;project&gt; par le nom du projet que vous créez.
    2. Confirmez que les objets de stratégie réseau dans le nouveau modèle de projet existent dans le nouveau projet:

      $ oc get networkpolicy
      NAME                           POD-SELECTOR   AGE
      allow-from-openshift-ingress   <none>         7s
      allow-from-same-namespace      <none>         7s
      Copy to Clipboard Toggle word wrap

En tant qu’administrateur de clusters, vous pouvez configurer vos stratégies réseau pour fournir une isolation réseau multilocataire.

Note

La configuration des stratégies réseau telles que décrites dans cette section fournit une isolation réseau similaire au mode multilocataires d’OpenShift SDN dans les versions précédentes de Red Hat OpenShift Service sur AWS.

Configurez votre projet pour l’isoler des pods et services dans d’autres espaces de noms de projet.

Conditions préalables

  • Le cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tels que le plugin réseau OVN-Kubernetes, avec mode: NetworkPolicy set.
  • Installation de l’OpenShift CLI (oc).
  • Il est connecté au cluster avec un utilisateur avec des privilèges d’administrateur.

Procédure

  1. Créez les objets de NetworkPolicy suivants:

    1. D’une politique nommée Autor-from-openshift-ingress.

      $ cat << EOF| oc create -f -
      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-ingress
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                policy-group.network.openshift.io/ingress: ""
        podSelector: {}
        policyTypes:
        - Ingress
      EOF
      Copy to Clipboard Toggle word wrap
      Note

      le label policy-group.network.openshift.io/ingress: "" est l’étiquette de sélecteur d’espace de noms préférée pour OVN-Kubernetes.

    2. D’une politique nommée Autorisation- from-openshift-monitoring:

      $ cat << EOF| oc create -f -
      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-monitoring
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                network.openshift.io/policy-group: monitoring
        podSelector: {}
        policyTypes:
        - Ingress
      EOF
      Copy to Clipboard Toggle word wrap
    3. D’une politique nommée allow-same-namespace:

      $ cat << EOF| oc create -f -
      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: allow-same-namespace
      spec:
        podSelector:
        ingress:
        - from:
          - podSelector: {}
      EOF
      Copy to Clipboard Toggle word wrap
    4. D’une politique nommée Author-from-kube-apiserver-operator:

      $ cat << EOF| oc create -f -
      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-kube-apiserver-operator
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                kubernetes.io/metadata.name: openshift-kube-apiserver-operator
            podSelector:
              matchLabels:
                app: kube-apiserver-operator
        policyTypes:
        - Ingress
      EOF
      Copy to Clipboard Toggle word wrap

      Consultez le nouveau contrôleur kube-apiserver-operator webhook pour valider la santé du webhook.

  2. Facultatif : Pour confirmer que les stratégies réseau existent dans votre projet actuel, entrez la commande suivante:

    $ oc describe networkpolicy
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    Name:         allow-from-openshift-ingress
    Namespace:    example1
    Created on:   2020-06-09 00:28:17 -0400 EDT
    Labels:       <none>
    Annotations:  <none>
    Spec:
      PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
      Allowing ingress traffic:
        To Port: <any> (traffic allowed to all ports)
        From:
          NamespaceSelector: network.openshift.io/policy-group: ingress
      Not affecting egress traffic
      Policy Types: Ingress
    
    
    Name:         allow-from-openshift-monitoring
    Namespace:    example1
    Created on:   2020-06-09 00:29:57 -0400 EDT
    Labels:       <none>
    Annotations:  <none>
    Spec:
      PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
      Allowing ingress traffic:
        To Port: <any> (traffic allowed to all ports)
        From:
          NamespaceSelector: network.openshift.io/policy-group: monitoring
      Not affecting egress traffic
      Policy Types: Ingress
    Copy to Clipboard Toggle word wrap

Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat