0

I am trying to understand how companies detect that a Kuberentes pod is running a container that is based on a container image that is out of date.

So, for example, say I have an application called WidgetOrdering. In my dockerfile I setup my WidgetOrdering container, first by having a from clause that that references the .Net 6 runtime container, then I add in additional instructions specific to my application. Then I deploy my WidgetOrdering container to Kubernetes.

After it has run for several months, .Net 6 releases a new version of their runtime container with some security patches in it. I need to know what versions of the .Net 6 container I have running in my cluster so I can target them for updating.

How do people check Kubernetes to see what "base" containers are running in their cluster?

1 Answer 1

1

Typically you don't do this in Kubernetes. Instead you do this in your CI pipeline or by scanning images on the registry. In the CI pipeline, the easy option is to periodically rebuild and redeploy the image on a schedule. This not only picks up changes in the base image, but any other external dependencies that may have changed since the previous build.

To check an image in the registry, this requires metadata like annotations to be defined on the image. OCI has documented standard annotations that can be used specifically for this:

  • org.opencontainers.image.base.digest: Digest of the image this image is based on (string)
  • org.opencontainers.image.base.name: Image reference of the image this image is based on (string)

As an example, using one of my own projects:

$ regctl manifest get ghcr.io/regclient/regctl:alpine --format '{{jsonPretty .Annotations}}'
{
  "oci.opencontainers.image.base.digest": "sha256:124c7d2707904eea7431fffe91522a01e5a861a624ee31d03372cc1d138a3126",
  "oci.opencontainers.image.base.name": "alpine:3",
  "oci.opencontainers.image.created": "2023-04-14T23:41:20Z",
  "oci.opencontainers.image.revision": "847254c7ac7d6f027dcdfb196a9aa4c11eb61ed9",
  "oci.opencontainers.image.source": "https://github.com/regclient/regclient.git"
}

$ regctl image digest alpine:3
sha256:124c7d2707904eea7431fffe91522a01e5a861a624ee31d03372cc1d138a3126

You can see the base name alpine:3 has the same digest from when this image was last built. Note that this metadata is not automatically added by most image build tooling. The steps used to add this in my own project can be seen in the github actions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.