If you are curious how sandboxed containers look like from the inside compared to normal containers, this thread will be covering the basics.
@openshift sandboxed containers is used to bootstrap and configure the runtime (aka @katacontainers) for the extra layer of isolation. It is also worth noting, that in all the following snippets, NO other fancy hardening is done (e.g., admission controllers, PSPs, PSA, SELinux,…). Don’t try this at home!
This is to highlight the effect of sandboxing alone compared to vanilla runtimes.
Let’s gooo…
HostPID
Controls whether the pod containers can share the host process ID namespace
Ref: kubernetes.io/docs/concepts/…
Sandboxing effect: Host processes are not exposed in the sandbox.
HostIPC
Controls whether the pod containers can share the host IPC namespace
Ref: kubernetes.io/docs/concepts/…
Sandboxing effect: Memory sharing is disabled in the sandbox.
HostNetwork
Controls whether the pod may use the node network namespace
Sandboxing effect: This is an easy one, HostNetwork is not even possible, remember kernel isolation is in effect (this is technically a “VM”).
Ref: kubernetes.io/docs/concepts/…
Privileged
A “privileged” container is given access to all devices on the host
Ref: kubernetes.io/docs/concepts/…
Sandboxing effect: Access to host devices are not allowed in the sandbox.
For more information on @katacontainers, checkout their doc page katacontainers.io and if you want to deep-dive, here is an end-to-end interactive flow: thinglink.com/scene/14012360…
OpenShift sandboxed containers
Finally, for more information on sandboxing with @openshift sandboxed containers checkout:
-
The documentation: docs.openshift.com/container-plat…
-
Our blog series: cloud.redhat.com/blog/tag/opens…
Layer-up, it’s worth it :)