OCI Supply Chain

OCI artefacts and registries provide the ability to further increase the security in the delivery stage of the Software supply chain. Among several new features coming into the software delivery realm like SBOMs, we are now providing signing and signature validation of our OCI images. In the future, we will also target third-party images that are vetted for SKA usage and the list of artefacts will be expanded to cover other types of artefacts such as Helm Charts, python packages and executables.

OCI supply chain specificities

This diagram reflects the changes relative to the generic software supply chain diagram provided. Mainly, we have switched from Nexus to Harbor as it provides a nicer interface to view signatures and allows us to block images from being used when they have critical vulnerabilities or haven’t been signed. Signing the OCI artefacts within the realm of our secure runners helps guaranteeing the provenance of the artefacts themselves, being that the signatures used can be checked downstream. Both the preferred OCI engine - Podman - and Kubernetes can be protected by checking the signature of the images before deployment. Below, you can find an example of what an artefact on Harbor looks like:

Artefacts in Harbor

The signed checkmark, as well as the result of the vulnerability scanning, provide visible queues on the compliance of the artefact.

OCI Cache Priming - SKAO OCI Daemon

As seen previously, we switched to a central artefact repository that allows signatures and SBOMs to assure the provenance of OCI images. Even so, the compute nodes are still connected to the internet which makes them susceptible to attacks. The SKA OCI Daemon bridges that gap, enabling the secure priming of OCI images into compute nodes, reducing deployment time and allowing for air-gapped environments. It can be deployed as a standalone container or via a Helm chart and it is capable of enforcing image signature validation in all operation modes. It keeps a local OCI-layout (on-disk) registry that can be shared among various instances of OCI Daemons, reducing layer copy operations and storage usage. Lets look at some of the features that enable this functionality:

  • Deployable as a standalone container or via a Helm chart

  • Anonymous, Basic and Token authentication for OCI registries

  • Enforcement of OCI image signatures and referrers

  • Use of multiple OCI registries as mirrors

  • Compatible with existing local-cache (Nexus) pull-through configurations

  • Two operation modes:

    • cache: Prime other OCI registries (e.g., registry:2, Nexus, Zot)

    • node: Prime OCI engines (containerd, Docker, Podman) on compute nodes

  • Support for air-gapped environments using only pre-approved OCI images

  • Parallelised architecture for high-performance operations

OCI Daemon reference production architecture

The OCI Daemon allows to securely prime datacentres that are physically separated with minimal infrastructure overhead, reducing or eliminating OCI image pull times in the datacentres running workloads. More than that, it allows for seggregated networks to be established and to air-gap critical resources without any impact to deployment strategies.

You can learn how to operate the OCI Daemon and leverage its capabilities.