This is unreleased documentation for SUSE® Virtualization v1.6 (Dev).

Virtual Machine Isolation

Isolation between virtual machines is typically achieved using either VLANs (in traditional networks) or virtual switches (in Kube-OVN). If you want to isolate virtual machines within the same virtual switch network, you can use either of the following to achieve the required micro-segmentation:

Subnet access control lists (ACLs): Apply rules to a subnet used by virtual machines.
Kubernetes network policies: Apply rules within network namespaces and using pod selectors.

Subnet ACLs

For more information about the schema and usage guidelines, see Subnet ACL and ACL API Reference in the Kube-OVN documentation.

Examples

Example 1: All virtual machines within the 172.20.10.0/24 subnet, except those with the addresses 172.20.10.2 and 172.20.10.3 in the subnet range 172.20.10.0/30, are allowed to communicate with each other.

Kube-OVN automatically adds the gateway address 172.20.10.1 to the excludeIps list, preventing it from being assigned to any virtual machines. However, communication to and from the gateway address is also affected.

  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

Example 2: All virtual machines within the 172.20.10.0/24 subnet, except those with the address 172.20.10.3, are allowed to communicate with each other. Virtual machines with the address 172.20.10.2 are allowed to communicate because ACL rule execution is based on priority. For this subnet, rules with a priority value of 1006 are executed before 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

Example 3: Virtual machines with the address 172.20.10.2 are allowed to communicate with other virtual machines. However, traffic in the opposite direction is blocked. No virtual machines are allowed to communicate with 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

Example 4: TCP traffic originating from port 9501 and ip address 172.20.10.6 is blocked on the vswitch1 subnet.

  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

Network Policies

NetworkPolicy rules deny traffic by default. To avoid affecting other pods, ensure the following:

All required match conditions are added to the policy.
Traffic is isolated using pod selectors and namespaces.

The examples in this document focus on achieving isolation between virtual machines within the same subnet.

For more information, see Network Policies in the Kubernetes documentation and NetworkPolicy Logging in the Kube-OVN documentation.

Examples

The following virtual machines are created in the default namespace and are attached to the overlay network created for the subnet range 172.20.10.0/24.

Virtual Machine IP Address

Virtual Machine	IP Address
`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

Example 1: VM1 and VM2 are allowed to communicate with each other because their addresses are within the subnet 172.20.10.0/30. All other traffic in the default namespace, including traffic to and from VM3, VM4, and VM5, is blocked.

  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

Example 2: VM1 and VM2 are allowed to communicate with each other and with other virtual machines in the subnet 172.20.10.0/24. However, other virtual machines in that subnet cannot communicate with VM1, VM2, and each other. This is because the ingress policy only allows traffic originating from 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
```
Example 3: VM1 and VM2 are allowed to communicate with each other, but not with other virtual machines in the subnet 172.20.10.0/24. The other virtual machines in the same subnet can communicate with VM1 and VM2. This is because the egress policy allows traffic to be sent to 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
```

Example 4: VM2 is allowed to communicate with VM1, but not with other virtual machines in the subnet 172.20.10.0/24. This is because a pod selector label is applied to VM2. All other virtual machines in the same subnet can communicate with VM1 and each other.

  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