What Next For The Open Container Initiative (OCI)?
Under the esteemed auspices of the Linux Foundation sits the Open Container Initiative, an open governance structure built for the express purpose of creating open industry standards around container formats and runtimes. Known to its friends as the OCI, what does this body do, where is it going next, and what’s so important about container formats and runtimes in the first place?
As we know, a container runtime is a base-level infrastructure-level element of a disaggregated computing system that enables containers to exist within their host operating system. A key part of the DevOps pipeline, a container runtime oversees actions such as pulling container images from a container registry, running the container itself and onward tasks and functions related to the container’s lifecycle and wellbeing.
Three Primary Container Specs
The OCI understands the need to oversee the entire universe of containers and, as such, its purview extends over the management of three primary container specification “realms” or actions today:
- The container image specification itself.
- The process governing how a container runtime retrieves a container image.
- The steps that underpin how a container image is unpacked, layered mounted and executed.
These steps, sequences, stages and specifications are all based on Docker’s work in this space; which itself was work that Docker donated to the initiative to champion the need for an open and interoperable ecosystem. Indeed, the OCI was established by Docker alongside several other container vendors.
According to the OCI, it currently contains three specifications: The Runtime Specification (runtime-spec), the Image Specification (image-spec) and the Distribution Specification (distribution-spec). “The Runtime Specification outlines how to run a ‘filesystem bundle’ is unpacked on disk. At a high level an OCI implementation would download an OCI Image and then unpack that image into an OCI Runtime filesystem bundle. At this point the OCI Runtime Bundle would be run by an OCI Runtime,” notes the OCI.
OCI has been used to package objects other than container images for some time, including projects like Helm, OPA and Wasm. The guidance for how projects should implement artifacts has now been codified into the image specification.
Container Runtime Security
As the proliferation of enterprise IT systems running containers continues to widen, the sometimes thorny issue of container runtime security will continue to rear its head. This process is not always as simple as it sounds, and that’s because a good deal of the security provisioning and control for containers happens outside the scope of the container runtime. Functions and processes such as SAST & IAST scanner, secure sourcing, application fuzz testing and applying policies to handle tasks like network access control for container traffic management all need to be secured.
According to Sysdig’s analysis of where the OCI’s work is focused when an attack event related to an exploit gets discovered and executed in a container, it will expose all running services on the host and may lead to further privilege escalations. Two approaches can limit this: Running the containers in a sandbox or running them in a virtualization framework.
Hope For Expanded Scope
“While the Open Container Initiative’s (OCI) current focus as of v.1.1. remains on container image formats and runtimes, there is potential for expanding its scope,” said Nigel Douglas, senior developer advocate at Sysdig, speaking to Cloud Native Now. “An expanded OCI scope is likely to include additional aspects of container technology, such as networking and inter-container communication if deemed necessary by the community. These additional aspects would be a particular interest for projects such as Cilium, Calico, Istio and Linkerd as they attempt to provide better standards for cloud workload networking.”
He further thinks that probably the most interesting change that came with v.1.1 of OCI was registry transition support, which now provides backward compatibility. This allows registries to gradually adopt new features without disrupting existing workflows. For instance, registries that do not support the referrers API will still function correctly with fallback mechanisms.
“The focus on backward compatibility and flexible client behavior underscores OCI’s commitment to a gradual and inclusive upgrade path. This approach facilitates smoother transitions and accommodates varying levels of registry support, promoting a more adaptable ecosystem,” said Sysdig’s Douglas.” OCI’s emphasis on maintaining compatibility with existing registries while introducing new features reflects a balance between fostering innovation and ensuring broad adoption. The decision to avoid a new manifest type in favor of enhancing the existing one highlights the challenge of implementing new standards without disrupting established ecosystems.”
Kubernetes management platform specialist Mirantis contributes to the OCI community primarily through its “maintainership” of Moby (an open framework designed to help assemble and accelerate specialized container systems), which sees it providing implementations of OCI-governed standards. CTO Shaun O’Meara says this often leads to contributions to other OCI-related projects such as containerd and runc.
Implementation Reconciliation Situations
“It also leads to contributions to less related projects such as Git especially when security concerns are raised by the community to the Moby project that involve other open source products,” explained O’Meara. “In some cases, discrepancies have been identified between OCI intended behavior and actual implementation which require reconciliation, at which point Mirantis developers have actively worked together with other key stakeholders to determine the proper course of action between either modifying application behavior or addressing through modifications to OCI specifications.”
Over at Kubernetes and Docker Development Environment Management (DEM) company Daytona, the team is particularly interested in the sandbox approach to container runtime security. Co-founder and CTO Vedran Jukic highlights the fact that the ability to introduce a proxy layer between the running container and the kernel, as outlined in the OCI’s work, aligns well with his firm’s focus on robust security measures for containerized environments. “While technologies like Kata Containers and Sysbox have made significant strides in this area, we’d love to see another option emerge. We believe additional innovations in sandboxed container runtimes could further enhance protection and flexibility for our clients running diverse workloads,” said Jukic.
Thierry Carrez, OpenInfra Foundation’s general manager is upbeat about the project as a whole and says that the OCI is a “good example” of how open-source collaboration processes can be used to define and maintain standard interfaces that facilitate implementation by diverse actors.
“Thanks to OCI’s work, Kata Containers can easily be substituted to the classic runC container runtime to add isolation and security. At this point, the specifications defined by OCI are pretty mature, as are the conformance test suites. While they may still evolve with new requirements from implementing tools, I would expect them to be mostly in maintenance mode going forward,” said Carrez.
The work the OCI is doing to ensure interoperability in the container ecosystem is essential to realizing the business benefits of speed, portability and developer efficiency that containers promise. But, says Josh Dobies, VP of product at Bluerock Systems, interoperability is a functional requirement whereas security tends to be a non-functional one if it’s a requirement at all.
“Moreover, [security] tends to be an implementation detail that is out-of-scope for these types of standards and something that is left to the organizations that build the runtimes themselves,” hastens Dobies. “As we’ve seen, different OCI-compliant runtimes have had different vulnerabilities that are unrelated to their implementations of OCI specifications, and containers themselves were never intended as hard security boundaries, so it’s critical to build out foundational infrastructure that can provide the necessary security as more and more of our digital world moves to this new software architecture.”
Containerized Contentment
Open standards are a crucial part of the open source community and OCI has been a key contributing factor to the success and widespread adoption of containers and Kubernetes. This is the view of Sam Marland, manager, solution architecture for Red Hat who helps us conclude here by saying that by removing the competition from the container layer, the existence of the project itself and the manifestation of the OCI standard has meant that the cloud-native developer and data science community has been able to focus on improving the experience of using containers.
