In the rapidly shifting landscape of container images, relying solely on DockerHub for your Kubernetes workflows exposes you to supply chain interruptions and image unavailability. Notably, the unpublishing of Bitnami images by Broadcom left many DevOps teams scrambling for alternatives and showcased the risks of relying on external registries. This guide walks you through configuring Sonatype Nexus as a DockerHub proxy for MicroK8s, ensuring your critical images remain available and under your own control.

Why Use Nexus as a Docker Proxy?#

Proxying DockerHub through Sonatype Nexus provides several advantages for modern Kubernetes environments:

  • Resilience: Images cached locally are available even if DockerHub is down or images are removed unexpectedly (as happened with Bitnami images due to Broadcom’s acquisition).[^1]
  • Speed: Pulling images is much faster from an on-premises proxy, reducing build and deployment times.
  • Security and Auditing: You gain visibility into all images used in your environment and can control what is cached or proxied.
  • Compliance: Prevent your clusters from downloading images directly from the Internet, supporting strict enterprise policies.

How MicroK8s Leverages a Private Docker Registry#

In this scenario, MicroK8s is configured to use a hosts.toml mapping for DockerHub. When you attempt to pull an image from docker.io, MicroK8s will transparently proxy those requests through your Nexus repository at nexus.home:21000, allowing greater control and assurance that required images remain available for future deployments.

Preparing Sonatype Nexus to Share a Docker Proxy#

To serve as a DockerHub proxy, you’ll need to configure Nexus Repository Manager as follows:

  1. Create a Docker (proxy) Repository:
    • Log in to your Nexus UI.
    • Navigate to the Repositories section and click “Create repository”.
    • Select “docker (proxy)”.
    • In the settings, set the Remote storage URL to https://registry-1.docker.io.
    • Choose an available port (e.g., 21000) for the HTTP connector—this is where MicroK8s will connect.
    • (Insert screenshot here of port configuration page)
    • Save and note the repository URL (e.g., https://nexus.home:21000).
  2. Enable Docker Bearer Token Realm:
    • Visit Administration > Security > Realms.
    • Ensure “Docker Bearer Token Realm” is enabled and moved to the right column.
  3. Configure Anonymous Access (Optional but common for internal use):
    • Under Administration > Security > Anonymous, enable Anonymous Access for read (pull) actions if your cluster nodes don’t use authentication.
  4. Firewall and SSL Settings:
    • Make sure the chosen port is open within your network/firewall.
    • For production, configure SSL certificates and expose the registry via HTTPS.

Nexus

Including MicroK8s containerd Configuration Details#

MicroK8s leverages containerd as its container runtime. The proxy configuration for DockerHub via Nexus is reflected in the containerd registry config.

Inside the MicroK8s snap directory, the containerd configuration file template at /var/snap/microk8s/current/args/containerd-template.toml contains the following section:

# 'plugins."io.containerd.grpc.v1.cri".registry' contains config related to the registry
[plugins."io.containerd.grpc.v1.cri".registry]
  config_path = "${SNAP_DATA}/args/certs.d"

This snippet tells containerd to look under the certs.d directory within the Snap data path for registry-specific TLS and mirror configuration, including your custom hosts.toml for docker.io.

This is why the proxy declaration in:

/var/snap/microk8s/current/args/certs.d/docker.io/hosts.toml

with

server = "https://docker.io"

[host."https://nexus.home:21000"]
  capabilities = ["pull", "resolve"]

works seamlessly: containerd reads this configuration and routes requests to DockerHub through the Nexus proxy at nexus.home:21000.

Risks of Relying Solely on DockerHub#

The Bitnami/Broadcom incident is a clear warning: images—sometimes critical ones—can disappear from public registries without notice, breaking builds, delaying deployments, or even blocking critical security updates. By hosting a proxy:[^1]

  • You keep using the standard docker.io image names in manifests.
  • Cached images remain available even if they’re deleted upstream.
  • You control what’s allowed into your runtime environment.

Conclusion#

Configuring Sonatype Nexus as a DockerHub proxy for MicroK8s guarantees high availability and security for your container images while shielding your infrastructure from volatility in public registries. This proactive step ensures a resilient and compliant DevOps pipeline—regardless of upstream changes.[^1]