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

Virtual Machine Isolation

All features that use Kube-OVN are considered experimental. For more information about experimental features, see Feature Labels.

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 information about the schema and usage guidelines, see Subnet ACL and ACL API Reference in the Kube-OVN documentation.

Configuring subnet ACLs

For information about basic subnet configuration, see Subnet Settings.

On the Access Control List tab, define traffic rules with the following components:

Action: Action to take when traffic matches the rule.
Direction: Traffic flow to which the rule applies (ingress or egress).
Priority: Integer that determines when the rule is evaluated. Rules with larger values are evaluated first (for example, 1000 takes precedence over 100).
Match: Packet filtering criteria, such as the source or destination IP address.

Subnet ACL 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.

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

Configuring network policies

On the SUSE Virtualization UI, go to Overlay Networks → Policies.
Click Create.
On the Ingress Rules tab, configure the following settings:
- Sources: IP blocks, namespaces, or pods from which inbound traffic is permitted.
- Allowed ports: Network ports and protocols open to inbound traffic.
On the Egress Rules tab, configure the following settings:
- Targets: IP blocks, namespaces, or pods to which outbound traffic is permitted.
- Allowed ports: Network ports and protocols permitted for outbound traffic.
On the Selectors tab, define rules that select the workload pods to which this network policy applies.
On the Labels and Annotations tab, configure the following settings:
- Labels: Key-value pairs used to categorize and filter the NetworkPolicy resource.
- Annotations: Non-identifying metadata used by external tools or system controllers.
Click Create.

Network policy examples

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

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