Goal

Katacontainers is a sandboxed runtime that adds an extra layer of isolation through the use of virtualization. This isolation adds some tech-restricted defaults that applications might not be aware of. For example, it is not possible to use hostNetwork or hostPID (i.e., share the host PID and Network namespaces).

In addition to the tech-restriction, SCC will be exposing the definition of ` EnsuredRuntimeClasses` and `AllowedRuntimeClasses` to restrict what runtime a pod can use (or who can use a specific runtime e.g., Kata). It is also important to understand and validate how to integrate with such API from the Katacontainers perspective.  

The goal of this EPIC is to understand other SCC dependencies and define a process for how SCC is used with Kata.

User-stories

• As a cluster-admin I would like to enforce isolation on all payloads deployed by certain users using katacontainers.
• As a cluster-admin, I would like to specify a runtimeClass in my SCC and have it respected. 

Requirements

• Test SCC with Katacontainers.
• Identify relaxed permissions that won't work with Kata.
• Document those permissions.

Notes

Contact person for the SCC API: Mrunal Patel

References

[1] https://github.com/kata-containers/runtime/issues/2633