Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi.

Isolation des machines virtuelles

Toutes les fonctionnalités utilisant Kube-OVN sont considérées comme expérimentales. Pour plus d’informations sur les fonctionnalités expérimentales, voir Étiquettes de fonctionnalités.

L’isolation entre les machines virtuelles est généralement réalisée à l’aide de VLAN (dans les réseaux traditionnels) ou de commutateurs virtuels (dans Kube-OVN). Si vous souhaitez isoler des machines virtuelles au sein du même réseau de commutateur virtuel, vous pouvez utiliser l’une des options suivantes pour obtenir la micro-segmentation requise :

Listes de contrôle d’accès (ACL) de sous-réseau : Appliquez des règles à un sous-réseau utilisé par des machines virtuelles.
Politiques réseau Kubernetes : Appliquez des règles au sein des espaces de noms réseau et en utilisant des sélecteurs de pods.

ACL de sous-réseau

Pour plus d’informations sur le schéma et les directives d’utilisation, voir ACL de sous-réseau et Référence API ACL dans la documentation Kube-OVN.

Exemples

Exemple 1 : Toutes les machines virtuelles au sein du sous-réseau 172.20.10.0/24, sauf celles ayant les adresses 172.20.10.2 et 172.20.10.3 dans la plage de sous-réseau 172.20.10.0/30, sont autorisées à communiquer entre elles.

Kube-OVN ajoute automatiquement l’adresse de passerelle 172.20.10.1 à la liste excludeIps, empêchant son attribution à des machines virtuelles. Cependant, la communication vers et depuis l’adresse de passerelle est également affectée.

  apiVersion: kubeovn.io/v1
  kind: Subnet
  metadata:
    name: vswitch1
  spec:
    acls:
    - action: drop
      direction: to-lport
      match: ip4.dst == 172.20.10.0/30
      priority: 1005
    - action: drop
      direction: from-lport
      match: ip4.src == 172.20.10.0/30
      priority: 1005
    cidrBlock: 172.20.10.0/24
    excludeIps:
    - 172.20.10.1
    gateway: 172.20.10.1
    gatewayNode: ""
    natOutgoing: false
    private: false
    protocol: IPv4
    provider: vswitch1.default.ovn
    vpc: vpc1

Exemple 2 : Toutes les machines virtuelles au sein du sous-réseau 172.20.10.0/24, sauf celles ayant l’adresse 172.20.10.3, sont autorisées à communiquer entre elles. Les machines virtuelles ayant l’adresse 172.20.10.2 sont autorisées à communiquer car l’exécution des règles ACL est basée sur la priorité. Pour ce sous-réseau, les règles avec une valeur de priorité de 1006 sont exécutées avant 1005.

  apiVersion: kubeovn.io/v1
  kind: Subnet
  metadata:
    name: vswitch1
  spec:
    acls:
    - action: allow
      direction: to-lport
      match: ip4.dst == 172.20.10.2
      priority: 1006
    - action: allow
      direction: from-lport
      match: ip4.src == 172.20.10.2
      priority: 1006
    - action: drop
      direction: to-lport
      match: ip4.dst == 172.20.10.0/30
      priority: 1005
    - action: drop
      direction: from-lport
      match: ip4.src == 172.20.10.0/30
      priority: 1005
    cidrBlock: 172.20.10.0/24
    excludeIps:
    - 172.20.10.1
    gateway: 172.20.10.1
    gatewayNode: ""
    natOutgoing: false
    private: false
    protocol: IPv4
    provider: vswitch1.default.ovn
    vpc: vpc1

Exemple 3 : Les machines virtuelles ayant l’adresse 172.20.10.2 sont autorisées à communiquer avec d’autres machines virtuelles. Cependant, le trafic dans la direction opposée est bloqué. Aucune machine virtuelle n’est autorisée à communiquer avec 172.20.10.2.

  apiVersion: kubeovn.io/v1
  kind: Subnet
  metadata:
    name: vswitch1
  spec:
    acls:
    - action: drop
      direction: to-lport
      match: ip4.dst == 172.20.10.2
      priority: 1005
    cidrBlock: 172.20.10.0/24
    excludeIps:
    - 172.20.10.1
    gateway: 172.20.10.1
    gatewayNode: ""
    natOutgoing: false
    private: false
    protocol: IPv4
    provider: vswitch1.default.ovn
    vpc: vpc1

Exemple 4 : Le trafic TCP provenant du port 9501 et de l’adresse IP 172.20.10.6 est bloqué sur le sous-réseau vswitch1.

  apiVersion: kubeovn.io/v1
  kind: Subnet
  metadata:
    name: vswitch1
  spec:
    acls:
    - action: drop
      direction: from-lport
      match: ip4.src == 172.20.10.6 && tcp.src == 9501
      priority: 1005
    cidrBlock: 172.20.10.0/24
    excludeIps:
    - 172.20.10.1
    gateway: 172.20.10.1
    gatewayNode: ""
    natOutgoing: false
    private: false
    protocol: IPv4
    provider: vswitch1.default.ovn
    vpc: vpc1

Politiques Réseau

Les règles de NetworkPolicy refusent le trafic par défaut. Pour éviter d’affecter d’autres pods, assurez-vous de ce qui suit :

Toutes les conditions de correspondance requises sont ajoutées à la politique.
Le trafic est isolé à l’aide de sélecteurs de pods et d’espaces de noms.

Les exemples dans ce document se concentrent sur l’atteinte de l’isolement entre les machines virtuelles au sein du même sous-réseau.

Pour plus d’informations, consultez Politiques Réseau dans la documentation Kubernetes et Journalisation des NetworkPolicy dans la documentation Kube-OVN.

Exemples

Les machines virtuelles suivantes sont créées dans l’espace de noms default et sont attachées au réseau overlay créé pour la plage de sous-réseau 172.20.10.0/24.

Machine virtuelle Adresse IP

Machine virtuelle	Adresse IP
`VM1`	`172.20.10.2`
`VM2`	`172.20.10.3`
`VM3`	`172.20.10.4`
`VM4`	`172.20.10.5`
`VM5`	`172.20.10.6`

VM1

172.20.10.2

VM2

172.20.10.3

VM3

172.20.10.4

VM4

172.20.10.5

VM5

172.20.10.6

Exemple 1 : VM1 et VM2 sont autorisés à communiquer entre eux car leurs adresses se trouvent dans le sous-réseau 172.20.10.0/30. Tout autre trafic dans l’espace de noms default, y compris le trafic vers et depuis VM3, VM4 et VM5, est bloqué.

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: ip-block
    namespace: default
  spec:
    egress:
    - to:
      - ipBlock:
          cidr: 172.20.10.0/30
    ingress:
    - from:
      - ipBlock:
          cidr: 172.20.10.0/30
    policyTypes:
    - Ingress
    - Egress

Exemple 2 : VM1 et VM2 sont autorisés à communiquer entre eux et avec d’autres machines virtuelles dans le sous-réseau 172.20.10.0/24. Cependant, d’autres machines virtuelles dans ce sous-réseau ne peuvent pas communiquer avec VM1, VM2 et entre elles. C’est parce que la politique d’entrée n’autorise que le trafic provenant de 172.20.10.0/30.
```
  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: ip-block
    namespace: default
  spec:
    ingress:
    - from:
      - ipBlock:
          cidr: 172.20.10.0/30
    policyTypes:
    - Ingress
```
Exemple 3 : VM1 et VM2 sont autorisés à communiquer entre eux, mais pas avec d’autres machines virtuelles dans le sous-réseau 172.20.10.0/24. Les autres machines virtuelles dans le même sous-réseau peuvent communiquer avec VM1 et VM2. C’est parce que la politique de sortie permet d’envoyer du trafic vers 172.20.10.0/30.
```
  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: ip-block
    namespace: default
  spec:
    egress:
    - to:
      - ipBlock:
          cidr: 172.20.10.0/30
    policyTypes:
    - egress
```

Exemple 4 : VM2 est autorisé à communiquer avec VM1, mais pas avec d’autres machines virtuelles dans le sous-réseau 172.20.10.0/24. C’est parce qu’une étiquette de sélecteur de pod est appliquée à VM2. Toutes les autres machines virtuelles dans le même sous-réseau peuvent communiquer avec VM1 et entre elles.

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: ip-block
    namespace: default
  spec:
    podSelector:
      matchLabels:
        vm.kubevirt.io/name: VM2
    egress:
    - to:
      - ipBlock:
          cidr: 172.20.10.0/30
    ingress:
    - from:
      - ipBlock:
          cidr: 172.20.10.0/30
    policyTypes:
    - Ingress
    - Egress