Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

6.2. La politique de réseau d’administrateur

6.2.1. Administration d’OVN-Kubernetes AdminNetworkPolicy
Copier lien

6.2.1.1. AdminNetworkPlicy
Copier lien

A AdminNetworkPolicy (ANP) est une définition de ressources personnalisées à portée de cluster (CRD). En tant que service Red Hat OpenShift sur AWS, vous pouvez utiliser ANP pour sécuriser votre réseau en créant des stratégies réseau avant de créer des espaces de noms. De plus, vous pouvez créer des stratégies réseau à un niveau de cluster qui n’est pas submergé par les objets NetworkPolicy.

La principale différence entre les objets AdminNetworkPolicy et NetworkPolicy est que le premier est destiné aux administrateurs et qu’il s’agit d’un cluster étendu tandis que le second est destiné aux propriétaires de locataires et qu’il s’agit d’un espace de noms.

ANP permet aux administrateurs de spécifier ce qui suit:

  • La valeur prioritaire qui détermine l’ordre de son évaluation. La valeur inférieure est élevée, plus la préséance est élevée.
  • Ensemble de pods qui se compose d’un ensemble d’espaces de noms ou d’espaces de noms sur lesquels la stratégie est appliquée.
  • Liste des règles d’entrée à appliquer pour tous les trafics entrants vers le sujet.
  • Liste des règles de sortie à appliquer pour tous les trafics sortants du sujet.
Exemple d’AdminNetworkPolicy

Exemple 6.1. Exemple de fichier YAML pour un ANP

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: sample-anp-deny-pass-rules
1 

spec:
  priority: 50
2 

  subject:
    namespaces:
      matchLabels:
          kubernetes.io/metadata.name: example.name
3 

  ingress:
4 

  - name: "deny-all-ingress-tenant-1"
5 

    action: "Deny"
    from:
    - pods:
        namespaceSelector:
          matchLabels:
            custom-anp: tenant-1
        podSelector:
          matchLabels:
            custom-anp: tenant-1
6 

  egress:
7 

  - name: "pass-all-egress-to-tenant-1"
    action: "Pass"
    to:
    - pods:
        namespaceSelector:
          matchLabels:
            custom-anp: tenant-1
        podSelector:
          matchLabels:
            custom-anp: tenant-1
Copy to Clipboard Toggle word wrap
1
Indiquez un nom pour votre ANP.
2
Le champ spec.priority prend en charge un maximum de 100 ANP dans la plage de valeurs 0-99 dans un cluster. Le plus bas de la valeur, plus la priorité est élevée parce que la plage est lue dans l’ordre de la valeur la plus basse à la plus haute. Étant donné qu’il n’y a pas de garantie quant à la politique qui prime lorsque les PAN sont créés à la même priorité, fixent les PAN à des priorités différentes afin que cette priorité soit délibérée.
3
Indiquez l’espace de noms pour appliquer la ressource ANP.
4
ANP a à la fois des règles d’entrée et de sortie. Les règles ANP pour le champ spec.ingress acceptent les valeurs de Pass, Deny et Autoriser pour le champ d’action.
5
Indiquez un nom pour ingress.name.
6
Indiquez podSelector.matchLabels pour sélectionner les pods dans les espaces de noms sélectionnés par namespaceSelector.matchLabels en tant que pairs d’entrée.
7
Les ANP ont à la fois des règles d’entrée et de sortie. Les règles ANP pour le champ spec.egress acceptent les valeurs de Pass, Deny et Autoriser pour le champ d’action.

Ressources supplémentaires

6.2.1.1.1. AdminNetwork Actions de politique pour les règles
Copier lien

En tant qu’administrateur, vous pouvez définir Autoriser, refuser ou passer comme champ d’action pour vos règles AdminNetworkPolicy. Comme OVN-Kubernetes utilise un ACL à plusieurs niveaux pour évaluer les règles de trafic réseau, ANP vous permet de définir des règles de stratégie très fortes qui ne peuvent être modifiées que par un administrateur les modifiant, en supprimant la règle ou en les remplaçant en définissant une règle de priorité plus élevée.

AdminNetworkPolicy Permettre un exemple

L’ANP suivant qui est défini à la priorité 9 garantit que tout trafic d’entrée est autorisé à partir de l’espace de surveillance vers n’importe quel locataire (tous les autres espaces de noms) dans le cluster.

Exemple 6.2. Exemple de fichier YAML pour un fort Autoriser ANP

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: allow-monitoring
spec:
  priority: 9
  subject:
    namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
  ingress:
  - name: "allow-ingress-from-monitoring"
    action: "Allow"
    from:
    - namespaces:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
# ...
Copy to Clipboard Toggle word wrap

Il s’agit d’un exemple d’un fort Allow ANP parce qu’il n’est pas impropre à toutes les parties concernées. Aucun locataire ne peut s’empêcher d’être surveillé à l’aide d’objets NetworkPolicy et le locataire de surveillance n’a pas non plus son mot à dire sur ce qu’il peut ou ne peut pas surveiller.

Exemple de AdminNetworkPolicy Deny

L’ANP suivant qui est défini à la priorité 5 garantit que tout le trafic d’entrée de l’espace de surveillance est bloqué vers les locataires restreints (namespaces qui ont une sécurité d’étiquette: restreinte).

Exemple 6.3. Exemple de fichier YAML pour un fort Deny ANP

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: block-monitoring
spec:
  priority: 5
  subject:
    namespaces:
      matchLabels:
        security: restricted
  ingress:
  - name: "deny-ingress-from-monitoring"
    action: "Deny"
    from:
    - namespaces:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
# ...
Copy to Clipboard Toggle word wrap

Il s’agit d’un fort Deny ANP qui est non-surpassable par toutes les parties impliquées. Les propriétaires de locataires restreints ne peuvent pas s’autoriser à permettre la surveillance du trafic, et le service de surveillance de l’infrastructure ne peut rien gratter de ces espaces de noms sensibles.

Lorsqu’il est combiné avec l’exemple d’autorisation fort, l’ANP de surveillance par blocs a une valeur de priorité inférieure lui donnant une priorité plus élevée, ce qui garantit que les locataires restreints ne sont jamais surveillés.

Exemple d’AdminNetworkPolicy Pass

L’ANP suivant qui est défini à la priorité 7 garantit que tous les trafics entrants de l’espace de surveillance vers les locataires internes de l’infrastructure (namespaces qui ont des étiquettes de sécurité: interne) sont transmis au niveau 2 des ACL et évalués par les objets NetworkPolicy des espaces de noms.

Exemple 6.4. Exemple de fichier YAML pour un Pass ANP fort

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: pass-monitoring
spec:
  priority: 7
  subject:
    namespaces:
      matchLabels:
        security: internal
  ingress:
  - name: "pass-ingress-from-monitoring"
    action: "Pass"
    from:
    - namespaces:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
# ...
Copy to Clipboard Toggle word wrap

Cet exemple est une forte action Pass ANP parce qu’il délègue la décision aux objets NetworkPolicy définis par les propriétaires de locataires. Ce pass-surveillant ANP permet à tous les propriétaires de locataires regroupés au niveau de sécurité interne de choisir si leurs métriques doivent être grattées par le service de surveillance des infrastructures à l’aide d’objets NetworkPolicy couverts par l’espace de noms.

6.2.2. Base de données d’OVN-KubernetesAdminNetworkPolicy
Copier lien

6.2.2.1. Base de donnéesAdminNetworkPolicy
Copier lien

BaselineAdminNetworkPolicy (BANP) est une définition de ressources personnalisées à portée de cluster (CRD). En tant que service Red Hat OpenShift sur l’administrateur AWS, vous pouvez utiliser BANP pour configurer et appliquer des règles de stratégie réseau de base facultatives qui sont impérieuses par les utilisateurs utilisant des objets NetworkPolicy si nécessaire. Les actions en règle pour BANP sont autorisées ou refusées.

La ressource BaselineAdminNetworkPolicy est un objet monoton de cluster qui peut être utilisé comme une politique de garde-corps dans le cas où une politique de trafic passée ne correspond à aucun des objets NetworkPolicy dans le cluster. BANP peut également être utilisé comme un modèle de sécurité par défaut qui fournit des garde-corps que le trafic intra-cluster est bloqué par défaut et un utilisateur devra utiliser des objets NetworkPolicy pour permettre le trafic connu. Lors de la création d’une ressource BANP, vous devez utiliser par défaut le nom.

Le BANP permet aux administrateurs de spécifier:

  • D’un sujet qui consiste en un ensemble d’espaces de noms ou d’espaces de noms.
  • Liste des règles d’entrée à appliquer pour tous les trafics entrants vers le sujet.
  • Liste des règles de sortie à appliquer pour tous les trafics sortants du sujet.
Exemple de BaselineAdminNetworkPolicy

Exemple 6.5. Exemple de fichier YAML pour BANP

apiVersion: policy.networking.k8s.io/v1alpha1
kind: BaselineAdminNetworkPolicy
metadata:
  name: default
1 

spec:
  subject:
    namespaces:
      matchLabels:
          kubernetes.io/metadata.name: example.name
2 

  ingress:
3 

  - name: "deny-all-ingress-from-tenant-1"
4 

    action: "Deny"
    from:
    - pods:
        namespaceSelector:
          matchLabels:
            custom-banp: tenant-1
5 

        podSelector:
          matchLabels:
            custom-banp: tenant-1
6 

  egress:
  - name: "allow-all-egress-to-tenant-1"
    action: "Allow"
    to:
    - pods:
        namespaceSelector:
          matchLabels:
            custom-banp: tenant-1
        podSelector:
          matchLabels:
            custom-banp: tenant-1
Copy to Clipboard Toggle word wrap
1
Le nom de la stratégie doit être par défaut car BANP est un objet singleton.
2
Indiquez l’espace de noms pour appliquer l’ANP à.
3
BANP a à la fois des règles d’entrée et de sortie. Les règles BANP pour les champs spec.ingress et spec.egress acceptent les valeurs de Deny et Autoriser pour le champ d’action.
4
Indiquez un nom pour ingress.name
5
Indiquez les espaces de noms pour sélectionner les pods pour appliquer la ressource BANP.
6
Indiquez le nom podSelector.matchLabels des pods pour appliquer la ressource BANP.
Exemple de BaselineAdminNetworkPolicy Deny

Le singleton BANP suivant garantit que l’administrateur a mis en place une politique de déni par défaut pour tous les trafics de surveillance entrant dans les locataires au niveau de sécurité interne. Lorsqu’elle est combinée à l’exemple « AdminNetworkPolicy Pass », cette politique agit comme une politique de garde-corps pour tout trafic d’entrée qui est passé par la politique de surveillance des laissez-passer ANP.

Exemple 6.6. Exemple de fichier YAML pour une règle de garde-corps

apiVersion: policy.networking.k8s.io/v1alpha1
kind: BaselineAdminNetworkPolicy
metadata:
  name: default
spec:
  subject:
    namespaces:
      matchLabels:
        security: internal
  ingress:
  - name: "deny-ingress-from-monitoring"
    action: "Deny"
    from:
    - namespaces:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
# ...
Copy to Clipboard Toggle word wrap

Il est possible d’utiliser une ressource AdminNetworkPolicy avec une valeur Pass pour le champ d’action en conjonction avec la ressource BaselineAdminNetworkPolicy pour créer une politique multi-locataires. Cette politique multi-locataires permet à un locataire de recueillir des données de surveillance sur son application tout en ne recueillant pas simultanément des données auprès d’un deuxième locataire.

En tant qu’administrateur, si vous appliquez à la fois l’exemple d’action « AdminNetworkPolicy Pass » et l’exemple « BaselineAdminNetwork Policy Deny », les locataires ont la possibilité de choisir de créer une ressource NetworkPolicy qui sera évaluée avant le BANP.

À titre d’exemple, le locataire 1 peut mettre en place la ressource NetworkPolicy suivante pour surveiller le trafic d’entrée:

Exemple 6.7. Exemple de NetworkPolicy

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-monitoring
  namespace: tenant 1
spec:
  podSelector:
  policyTypes:
    - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
# ...
Copy to Clipboard Toggle word wrap

Dans ce scénario, la politique du locataire 1 serait évaluée après l’« exemple d’action AdminNetworkPolicy Pass » et avant l’exemple «BaselineAdminNetwork Policy Deny», qui nie toute pénétration de surveillance du trafic entrant dans les locataires avec un niveau de sécurité interne. Avec l’objet NetworkPolicy de Tenant 1 en place, ils pourront collecter des données sur leur application. Cependant, le locataire 2, qui n’a pas d’objets NetworkPolicy en place, ne sera pas en mesure de recueillir des données. En tant qu’administrateur, vous n’avez pas surveillé par défaut les locataires internes, mais vous avez créé un BANP qui permet aux locataires d’utiliser des objets NetworkPolicy pour remplacer le comportement par défaut de votre BANP.

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