Featured image of post Avoid private information leaks in your Docker images metadata

Avoid private information leaks in your Docker images metadata

Learn to remove metadata from your public Docker images

Please note that in this article we will not cover the deployment nor instructions on the usage of any version control system or container repository software, but are directly implying the use of both components.

If you are one of those who run their own servers at home or just away from being exposed to the Internet, but still get some of the work done there made public, you are probably interested in this article.

Recently I started publishing some of the Docker image builds I run on my own, for whoever might find the changes I introduce in others base images useful. Here is an example.

The issue

However, all the previous work before the image is pushed to public registries is run in my homelab. And for that reason I am especially interested in keeping all the details related to that part of my infrastructure private, as it is supposed to be.

This said, if you happen to run your own container registry but also want to make your images available (by uploading them to public container registries such as Docker Hub or GitHub Container Registry) there are a couple of things to be aware of.

In particular, I’m talking about these annotations: org.opencontainers.image.source and org.opencontainers.image.url (more details can be found here). When left intact, if you push a Docker image to a registry they will contain direct references to the Git repository where the image is being built from.

This is normally not a problem when the code is also hosted in public repositories, but this is not our case. Say our private Git server resolves to https://git.home.lab. Then we can check how it looks by inspecting the image, like this:

$ docker pull ghcr.io/mtnezm/nextcloud:latest
$ docker inspect ghcr.io/mtnezm/nextcloud:latest  |jq '.[] | .ContainerConfig | .Labels'
  "maintainer": "Miguel Martínez <[email protected]>",
  "org.opencontainers.image.created": "2023-01-29T12:57:51Z",
  "org.opencontainers.image.description": "Custom Docker Nextcloud image build",
  "org.opencontainers.image.revision": "dab535e710a65affbb517aecaa9fc02fe21df1f6",
  "org.opencontainers.image.source": "https://git.home.lab/mtnezm/nextcloud.git",
  "org.opencontainers.image.url": "https://git.home.lab/mtnezm/nextcloud.git"

There it is, a link to our private Git repository included in a worldwide accessible Docker image. Something that does not make sense at all.

Fixing it

As we said, there is no real value in keeping a URL to a private Git server exposed there, so one thing we can do here is setting a custom value for those labels in our image. In this case, as I am using Drone CI to build them, it can be done by adding these lines to the corresponding step in the pipeline:

- name: "Deploy"
  image: plugins/docker
    - org.opencontainers.image.source=REDACTED FOR PRIVACY
    - org.opencontainers.image.url=REDACTED FOR PRIVACY

If you are working directly with the Dockerfile, you can achieve it by adding these lines:

LABEL org.opencontainers.image.source=REDACTED FOR PRIVACY
LABEL org.opencontainers.image.url=REDACTED FOR PRIVACY

After applying that change, if we build, publish, pull and inspect the image again, we can verify how it looks now:

  "maintainer": "Miguel Martínez <[email protected]>",
  "org.opencontainers.image.created": "2023-01-29T13:22:49Z",
  "org.opencontainers.image.description": "Custom Docker Nextcloud image build",
  "org.opencontainers.image.revision": "30f0f6cff0f9a63af0cd990301d1f301b425df85",
  "org.opencontainers.image.source": "REDACTED FOR PRIVACY",
  "org.opencontainers.image.url": "REDACTED FOR PRIVACY"


This way we can keep references to the work that runs in our homelab out of the public eye. But then again you might wonder “how do we know what is the work behind that image in particular, and if we can trust you?” which is perfectly reasonable.

In this case, as we are talking about Docker images there is the Dockerfile for you to go and verify it line by line, but let me answer to that one with a different approach in a future post here at Vectops.


Built with Hugo