<p>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.</p>
<p>To check an image in the registry, this requires metadata like annotations to be defined on the image. <a href="https://github.com/opencontainers/image-spec/blob/main/annotations.md" rel="nofollow noreferrer">OCI has documented standard annotations</a> that can be used specifically for this:</p>
<blockquote>
<ul>
<li><code>org.opencontainers.image.base.digest</code>: Digest of the image this image is based on (string)</li>
<li><code>org.opencontainers.image.base.name</code>: Image reference of the image this image is based on (string)</li>
</ul>
</blockquote>
<p>As an example, using one of my own projects:</p>
<pre><code>$ regctl manifest get ghcr.io/regclient/regctl:alpine --format '{{jsonPretty .Annotations}}'
{
  &quot;oci.opencontainers.image.base.digest&quot;: &quot;sha256:124c7d2707904eea7431fffe91522a01e5a861a624ee31d03372cc1d138a3126&quot;,
  &quot;oci.opencontainers.image.base.name&quot;: &quot;alpine:3&quot;,
  &quot;oci.opencontainers.image.created&quot;: &quot;2023-04-14T23:41:20Z&quot;,
  &quot;oci.opencontainers.image.revision&quot;: &quot;847254c7ac7d6f027dcdfb196a9aa4c11eb61ed9&quot;,
  &quot;oci.opencontainers.image.source&quot;: &quot;https://github.com/regclient/regclient.git&quot;
}

$ regctl image digest alpine:3
sha256:124c7d2707904eea7431fffe91522a01e5a861a624ee31d03372cc1d138a3126
</code></pre>
<p>You can see the base name <code>alpine:3</code> 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 <a href="https://github.com/regclient/regclient/blob/499011b9588065557c2a9fa6eb5d6cfe0bf044c0/.github/workflows/docker.yml#L157-L159" rel="nofollow noreferrer">github actions</a>.</p>

CC BY-SA 4.0
2023-05-06T12:58:39.677Z
2023-05-06T12:58:39.677Z
BMitch
<p>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.</p>
<p>So, for example, say I have an application called WidgetOrdering.  In my <code>dockerfile</code> I setup my WidgetOrdering container, first by having a <code>from</code> 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.</p>
<p>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.</p>
<p>How do people check Kubernetes to see what &quot;base&quot; containers are running in their cluster?</p>

<docker><kubernetes><containers>
Way to detect base container version for pods
Vaccano
# Way to detect base container version for pods

(Asked by: username_0 on 2023-05-05)

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?

**Tags:** docker, kubernetes, containers


---

## 1 answers

### Answer by username_1 on 2023-05-06. Score: 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.


---

