Define Linux Network Devices

[aojea]

The proposed "netdevices" field provides a declarative way to specify which host network devices should be moved into a container's network namespace.

This approach is similar than the existing "devices" field used for block devices but uses a dictionary keyed by the interface name instead.

The proposed scheme is based on the existing representation of network device by the struct net_device
https://docs.kernel.org/networking/netdevices.html.

This proposal focuses solely on moving existing network devices into the container namespace. It does not cover the complexities of network configuration or network interface creation, emphasizing the separation of device management and network configuration.

A list of real use cases that justify this proposal is:

1. Pre-Configuring Physical Devices:

   • Scenario: A container requires a specific physical network interface with a complex IP configuration, RDMA or SR-IOV
   • Implementation:
     • Configure the physical interface on the host with the desired IP addresses, routing, and other settings. In kubernetes this can be done with DRA or Device Plugins.
     • Use netDevices to move the pre-configured interface into the container.

2. Creating and Moving Virtual Interfaces:

   • Scenario: A container needs to have its own unique MAC address on an existing physical network, without bridging.
   • Implementation:
     • Create the macvlan interface on the host, based on an existing physical interface.
     • Use netDevices to move the MACVLAN interface into the container.

3. Network Function Containers:

   • Scenario: A container acts as a network router or firewall.
   • Implementation:
     • Use netDevices to move multiple physical or virtual interfaces into the container.
     • The container's processes manage the network configuration, routing, and firewall rules.

References

• Linux network namespaces and interfaces
• runc implementation
• Kubernetes Network Drivers Slides

Implementations

• runc Linux Network Devices runc#4538
• crun linux: add support for net devices containers/crun#1750
• youki [FEATURE]: Define Linux Network Devices youki-dev/youki#3136

Fixes: #1239

[aojea]

/assign @samuelkarp

[AkihiroSuda]

https://github.com/opencontainers/runtime-spec/blob/main/features.md should be updated too

[aojea]

https://github.com/opencontainers/runtime-spec/blob/main/features.md should be updated too

updated and addressed the comments

[aojea]

AI @aojea (document the cleanup and destroy of the network interfaces)

[samuelkarp]

From the in-person discussion today:

• Net device lifecycle should follow the network namespace lifecycle
• @aojea will follow up to determine whether any cleanup actions need to be taken by the OCI runtime on a container being deleted
• @kad was concerned about restarts and error handling
• Should we prohibit the new netdev addition to an existing netns? IOW only allow this for containers where a new netns is created? What about containers where the root netns is used?

[utam0k]

This spec said "MUST" but, I think it can't do it in the rootless container because the rootless container doesn't have CAP_NET_ADMIN, right?

[utam0k]

I'm not sure we should take care of the rootless container.

[samuelkarp]

Could be an error in the case of a rootless container, if the runtime is not able to satisfy the MUST condition.

[utam0k]

Could be an error in the case of a rootless container, if the runtime is not able to satisfy the MUST condition.

+1 but It'd be better to clarify it in the spec.

[aojea]

added mor explanations about runtime and network devices lifecycle and runtime checks, PTAL

[aojea]

om the in-person discussion today:

• Net device lifecycle should follow the network namespace lifecycle
• @aojea will follow up to determine whether any cleanup actions need to be taken by the OCI runtime on a container being deleted
• @kad was concerned about restarts and error handling
• Should we prohibit the new netdev addition to an existing netns? IOW only allow this for containers where a new netns is created? What about containers where the root netns is used?

Pushed a new commit addressing those comments, the changelog is

• the network namespace lifecycle will move migratebale network devices and destroy virtual devides, the runtime MAY decide to do cleanup actions
• runtime MUST check the container has enough privileges and an associated network namespace and fail if the check fail
• removed the Mask field and use the Address field with CIDR notation (IP/Prefix) to deal with IPv4 and IPv6 addresses. Only one IP is allowed to be specified on purpose to simplify the operations and reduce risks
• Add a HardwareAddress field for use cases that require to set a
  specific mac or infiniband address

[utam0k]

@AkihiroSuda @rata This PR has already got 6 approvals. I think it's ready for merging. Can we merge it?

[giuseppe]

LGTM

[rata]

@utam0k Let's merge :)