
Lead Image © Corina Rosu, 123rf.com
CRI-O and Kubernetes Security
Critical Tool
Container runtimes continue to evolve at a fast rate, and Red Hat has shifted their focus in the direction of their own Podman container runtime in favor of Docker. Red Hat's open source contributions to Kubernetes also means that CRI-O has been adopted by their OpenShift enterprise platform as the runtime, and Red Hat Enterprise Linux will offer Podman for user interaction with containers in the future.
Although Docker still continues to be used as the universal container runtime, the popular Kubernetes container orchestrator moved over to CRI-O as a lightweight default runtime alternative a number of versions ago. CRI-O (Container Runtime Interface) began life at Red Hat in 2016 and was passed on to Kubernetes in 2019. Red Hat described the runtime when it was launched as benefiting from a "narrow focus [that] drives stability, performance and security features down the stack, allowing the cloud native ecosystem to reliably focus at the Kubernetes layer and above" [1].
Because CRI-O is likely to be entrenched in Kubernetes for the foreseeable future, learning about this relatively nascent and critical component is a useful exercise. For further information on alternative Kubernetes runtimes, you can refer to a document about container runtimes on the Kubernetes website [2].
In this article, I look at CRI-O in more detail and how the use of a troubleshooting tool in combination with an unexpected debugging companion enables developers to access Kubernetes resources without having to make changes directly to the Kubernetes cluster itself.
Jigsaw Puzzle
The precise definition of a container runtime is surrounded by confusion and ambiguity. The CRI-O runtime [3] is an Open Container Initiative (OCI)-compliant
...Buy this article as PDF
(incl. VAT)