Host patching strategy — what a Docker host needs and how often

A Docker host runs the same operating system as everything else you patch, and for most of its packages the usual rules apply: apply security updates promptly, automatically where you can.

Two things make it different. The docker-ce and containerd.io packages restart services that every workload on the machine depends on, and the container isolation model means several host libraries reach inside containers in ways that are not obvious from the package list.

What reaches into a container

Containers share the host kernel and, for some subsystems, the host’s policy configuration. A patch to any of these changes behaviour inside every container on the machine:

That last row is the one that surprises people, and it cuts both ways. A glibc CVE on the host does not affect containers, because each image ships its own libc. But it also means patching the host does not patch your containers: a glibc CVE inside myapp:release-2026-08 is fixed by rebuilding the image, and no amount of host patching will touch it.

The unattended-upgrades problem

Ubuntu and Debian ship unattended-upgrades and it is a good default. On a Docker host, the default configuration has a specific hazard.

$ grep -A 8 'Allowed-Origins' /etc/apt/apt.conf.d/50unattended-upgrades

Unattended-Upgrade::Allowed-Origins {
      "${distro_id}:${distro_codename}";
      "${distro_id}:${distro_codename}-security";
      "${distro_id}ESMApps:${distro_codename}-apps-security";
      "${distro_id}ESM:${distro_codename}-infra-security";
};

Read that carefully, because it is better news than the folklore suggests. The default allows only origins whose distro_id matches the distribution. Docker’s repository publishes with a different origin:

$ grep -hE '^(Origin|Label|Suite)' /var/lib/apt/lists/download.docker.com*InRelease

Label: Docker CE
Origin: Docker
Suite: noble

So a stock unattended-upgrades does not upgrade Docker. Origin: Docker is not in the allowed list.

# Is unattended-upgrades even enabled?
systemctl is-enabled unattended-upgrades.service apt-daily-upgrade.timer

# What does it consider in scope? (does not install anything)
sudo unattended-upgrade --dry-run --debug 2>&1 | head -40

# Anything else scheduled that touches apt?
sudo grep -rn 'apt-get\|apt ' /etc/cron.d/ /etc/cron.daily/ 2>/dev/null

# What is currently upgradable, and from which origin
apt list --upgradable 2>/dev/null

Making it explicit

Do not rely on the default staying the default. State the exclusion.

// Docker Engine and containerd restart their services from the package
// postinstall. On this host that stops every container unless live-restore
// is enabled, so both are upgraded only in a maintenance window.
Unattended-Upgrade::Package-Blacklist {
  "docker-ce$";
  "docker-ce-cli$";
  "containerd.io$";
};

Two details matter. The $ anchors the pattern — these are Python regular expressions matched against package names, and without the anchor docker-ce also matches docker-ce-rootless-extras. And putting this in your own file rather than editing 50unattended-upgrades means a package upgrade of unattended-upgrades cannot silently revert it.

The belt-and-braces version is an apt pin, which stops manual mistakes too:

Package: docker-ce docker-ce-cli containerd.io
Pin: origin download.docker.com
Pin-Priority: 100

Priority 100 means “installed, but do not upgrade automatically”. An explicit apt-get install docker-ce=<version> still works, which is exactly the behaviour you want: automatic runs skip it, maintenance windows do not.

Cadences

The kernel is separate from the automatic stream for one reason: installing a kernel is harmless and applying it requires a reboot. Automating the install without automating the reboot produces hosts that report as patched and are running the old kernel — the subject of the next lesson.

Knowledge check