20.2. Création d'une politique de réseau


En tant qu'utilisateur ayant le rôle admin, vous pouvez créer une stratégie de réseau pour un espace de noms.

20.2.1. Exemple d'objet NetworkPolicy

Un exemple d'objet NetworkPolicy est annoté ci-dessous :

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
1
Le nom de l'objet NetworkPolicy.
2
Un sélecteur qui décrit les pods auxquels la politique s'applique. L'objet de politique ne peut sélectionner que des pods dans le projet qui définit l'objet NetworkPolicy.
3
Un sélecteur qui correspond aux pods à partir desquels l'objet de politique autorise le trafic entrant. Le sélecteur correspond aux pods situés dans le même espace de noms que la NetworkPolicy.
4
Liste d'un ou plusieurs ports de destination sur lesquels le trafic doit être accepté.

20.2.2. Création d'une politique de réseau à l'aide de l'interface de ligne de commande

Pour définir des règles granulaires décrivant le trafic réseau entrant ou sortant autorisé pour les espaces de noms de votre cluster, vous pouvez créer une stratégie réseau.

Note

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

Conditions préalables

  • Votre cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tel que le fournisseur de réseau OpenShift SDN avec mode: NetworkPolicy. Ce mode est le mode par défaut pour OpenShift SDN.
  • Vous avez installé l'OpenShift CLI (oc).
  • Vous êtes connecté au cluster avec un utilisateur disposant des privilèges admin.
  • Vous travaillez dans l'espace de noms auquel s'applique la politique de réseau.

Procédure

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

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

      $ touch <policy_name>.yaml

      où :

      <policy_name>
      Spécifie le nom du fichier de stratégie réseau.
    2. Définissez une politique de réseau dans le fichier que vous venez de créer, comme dans les exemples suivants :

      Refuser l'entrée de tous les pods dans tous les espaces de noms

      Il s'agit d'une politique fondamentale, qui bloque tout réseau inter-pods autre que le trafic inter-pods autorisé par la configuration d'autres politiques de réseau.

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

      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: {}

      Autoriser le trafic entrant vers un pod à partir d'un espace de noms particulier

      Cette politique autorise le trafic vers les pods étiquetés pod-a à partir des pods fonctionnant sur 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
  2. Pour créer l'objet de stratégie de réseau, entrez la commande suivante :

    oc apply -f <policy_name>.yaml -n <namespace>

    où :

    <policy_name>
    Spécifie le nom du fichier de stratégie réseau.
    <namespace>
    Facultatif : Spécifie l'espace de noms si l'objet est défini dans un espace de noms différent de l'espace de noms actuel.

    Exemple de sortie

    networkpolicy.networking.k8s.io/deny-by-default created

Note

Si vous vous connectez à la console web avec les privilèges cluster-admin, vous avez le choix de créer une politique de réseau dans n'importe quel espace de noms du cluster directement dans YAML ou à partir d'un formulaire dans la console web.

20.2.3. Création d'une stratégie réseau de refus de tout par défaut

Il s'agit d'une politique fondamentale, qui bloque tout réseau inter-pods autre que le trafic réseau autorisé par la configuration d'autres politiques de réseau déployées. Cette procédure applique une politique par défaut : deny-by-default.

Note

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

Conditions préalables

  • Votre cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tel que le fournisseur de réseau OpenShift SDN avec mode: NetworkPolicy. Ce mode est le mode par défaut pour OpenShift SDN.
  • Vous avez installé l'OpenShift CLI (oc).
  • Vous êtes connecté au cluster avec un utilisateur disposant des privilèges admin.
  • Vous travaillez dans l'espace de noms auquel s'applique la politique de réseau.

Procédure

  1. Créez le fichier YAML suivant qui définit une politique deny-by-default 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
    1
    namespace: default déploie cette politique dans l'espace de noms default.
    2
    podSelector: est vide, cela signifie qu'elle correspond à tous les pods. Par conséquent, la politique s'applique à tous les modules de l'espace de noms par défaut.
    3
    Aucune règle ingress n'est spécifiée. Le trafic entrant est donc supprimé pour tous les pods.
  2. Appliquez la politique en entrant la commande suivante :

    $ oc apply -f deny-by-default.yaml

    Exemple de sortie

    networkpolicy.networking.k8s.io/deny-by-default created

20.2.4. Création d'une politique de réseau pour autoriser le trafic en provenance de clients externes

La politique deny-by-default étant en place, vous pouvez configurer une politique qui autorise le trafic des clients externes vers un pod portant l'étiquette app=web.

Note

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

Suivez cette procédure pour configurer une politique qui autorise un service externe à partir de l'Internet public directement ou en utilisant un équilibreur de charge pour accéder au module. Le trafic n'est autorisé que vers un pod portant l'étiquette app=web.

Conditions préalables

  • Votre cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tel que le fournisseur de réseau OpenShift SDN avec mode: NetworkPolicy. Ce mode est le mode par défaut pour OpenShift SDN.
  • Vous avez installé l'OpenShift CLI (oc).
  • Vous êtes connecté au cluster avec un utilisateur disposant des privilèges admin.
  • Vous travaillez dans l'espace de noms auquel s'applique la politique de réseau.

Procédure

  1. Créez une politique qui autorise le trafic provenant de l'Internet public directement ou en utilisant un équilibreur 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:
        - {}
  2. Appliquez la politique en entrant la commande suivante :

    $ oc apply -f web-allow-external.yaml

    Exemple de sortie

    networkpolicy.networking.k8s.io/web-allow-external created

Cette politique autorise le trafic en provenance de toutes les ressources, y compris le trafic externe, comme l'illustre le diagramme suivant :

Allow traffic from external clients

20.2.5. Création d'une politique de réseau autorisant le trafic vers une application à partir de tous les espaces de noms

Note

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

Suivez cette procédure pour configurer une stratégie qui autorise le trafic de tous les pods de tous les espaces de noms vers une application particulière.

Conditions préalables

  • Votre cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tel que le fournisseur de réseau OpenShift SDN avec mode: NetworkPolicy. Ce mode est le mode par défaut pour OpenShift SDN.
  • Vous avez installé l'OpenShift CLI (oc).
  • Vous êtes connecté au cluster avec un utilisateur disposant des privilèges admin.
  • Vous travaillez dans l'espace de noms auquel s'applique la politique de réseau.

Procédure

  1. Créez une politique qui autorise 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
    1
    Applique la politique 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 ne précisez pas namespaceSelector, aucun espace de noms n'est sélectionné, ce qui signifie que la stratégie n'autorise que le trafic provenant de l'espace de noms dans lequel la stratégie de réseau est déployée.

  2. Appliquez la politique en entrant la commande suivante :

    $ oc apply -f web-allow-all-namespaces.yaml

    Exemple de sortie

    networkpolicy.networking.k8s.io/web-allow-all-namespaces created

Vérification

  1. Démarrez un service web dans l'espace de noms default en entrant la commande suivante :

    $ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
  2. Exécutez la commande suivante pour déployer une image alpine dans l'espace de noms secondary et pour démarrer un shell :

    $ oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh
  3. Exécutez la commande suivante dans l'interpréteur de commandes et observez que la demande est autorisée :

    # wget -qO- --timeout=2 http://web.default

    Résultats attendus

    <!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>

20.2.6. Création d'une politique de réseau autorisant le trafic vers une application à partir d'un espace de noms

Note

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

Suivez cette procédure pour configurer une politique qui autorise le trafic vers un pod avec l'étiquette app=web à partir d'un espace de noms particulier. Vous pourriez vouloir faire ceci pour :

  • Restreindre le trafic vers une base de données de production aux seuls espaces de noms dans lesquels des charges de travail de production sont déployées.
  • Permet aux outils de surveillance déployés dans un espace de noms particulier de récupérer les mesures de l'espace de noms actuel.

Conditions préalables

  • Votre cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tel que le fournisseur de réseau OpenShift SDN avec mode: NetworkPolicy. Ce mode est le mode par défaut pour OpenShift SDN.
  • Vous avez installé l'OpenShift CLI (oc).
  • Vous êtes connecté au cluster avec un utilisateur disposant des privilèges admin.
  • Vous travaillez dans l'espace de noms auquel s'applique la politique de réseau.

Procédure

  1. Créez une politique qui autorise le trafic de tous les pods dans un espace de noms particulier avec un label purpose=production. Sauvegardez 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
    1
    Applique la politique uniquement aux pods app:web dans l'espace de noms par défaut.
    2
    Restreint le trafic aux seuls pods des espaces de noms portant l'étiquette purpose=production.
  2. Appliquez la politique en entrant la commande suivante :

    $ oc apply -f web-allow-prod.yaml

    Exemple de sortie

    networkpolicy.networking.k8s.io/web-allow-prod created

Vérification

  1. Démarrez un service web dans l'espace de noms default en entrant la commande suivante :

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

    $ oc create namespace prod
  3. Exécutez la commande suivante pour étiqueter l'espace de noms prod:

    $ oc label namespace/prod purpose=production
  4. Exécutez la commande suivante pour créer l'espace de noms dev:

    $ oc create namespace dev
  5. Exécutez la commande suivante pour étiqueter l'espace de noms dev:

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

    $ oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh
  7. Exécutez la commande suivante dans l'interpréteur de commandes et observez que la demande est bloquée :

    # wget -qO- --timeout=2 http://web.default

    Résultats attendus

    wget: download timed out

  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
  9. Exécutez la commande suivante dans l'interpréteur de commandes et observez que la demande est autorisée :

    # wget -qO- --timeout=2 http://web.default

    Résultats attendus

    <!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>

20.2.7. Ressources supplémentaires

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.

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 leBlog 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.

© 2024 Red Hat, Inc.