Review Hardware support tests and add more content about testsuite HOT 5 CLOSED

Added a few comments to the deck. Ideally everything related to hardware should be handled through Kubernetes (avoiding privileged access from a CNF)

from testsuite.

There is a long way to go though. Like GTP kernel tunnels need privileged access, and I bet XDP and eBPF are still not on the Device Plugin landscape. But I agree - avoid direct access to anything. A bit of concern is tht support for 3.10 kernel, but well ... that may drop at some pointl.

from testsuite.

I updated the title, more tests could be added, rewording the last question is recommended

from testsuite.

There is indeed a long way to go, but i'd rather try to set the bar high from the beginning. The GTP tunnels "only" requires net_admin capabilities, but that is still more access to the underlying system than I would consider cloud native :)

from testsuite.

A few thoughts based on some quick research and evaluation:

• No container (or pod) should have direct access to hardware
• No container (or pod) should run as privileged
• Any volume used by a pod must be separated from the host or other pods in the deployment
• Hardware resources must be requested through Kubernetes (native or plugin based)

If, for whatever reason, direct hardware or privileged access is needed, this must be done through containers using images specifically made for this purpose. These images must enforce restrictions necessary to ensure general security and proper separation between pods and between the host and pods.

Volume separation is already fairly well handled in Kubernetes, as documented here. Access to sensitive directories on the host must be limited by default, but potentially made possible through a set of managed images provided as part of the infrastructure (more details on this below)

Looking at the analysis already done by @denverwilliams here, the tools mentioned can also be used to help with conformance wrt. hardware.

Falco provides auditing that can help ensure pods stay conformant with requirements on hardware access. It also allows (partial/full) whitelisting of trusted images, that can be used to provide some level of direct hardware access to pods.

Another area of interest is networking. By default Kubernetes provides limited capabilities for network access to containers and pods. There are several ways of adding additional interfaces to containers, some require direct hardware access (physical ports), others host access (e.g. netlink). Another way to handle networks and interfaces is through the use of CNI plugins, and there is an ongoing discussion happening on the TUG mailing list.

Some hardware is available as resources through Kubernetes, e.g. CPU and memory (hugepages). Information about these can be found here. Similary, pods can be constrained to a sub-set of nodes using various concepts available through Kubernetes. More information about this can be found here

from testsuite.