GKE node pools running an image other than Container-Optimized OS
What does ZopNight detect here?
GKE node pools are flagged when their `imageType` is anything other than `COS` or `COS_CONTAINERD`, such as `UBUNTU_CONTAINERD`. Google calls Container-Optimized OS with containerd the recommended node image, maintained by a Google team that can patch it quickly, and it is the only image Autopilot uses.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1225 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Threshold | imageType not COS or COS_CONTAINERD |
| Source | ZopNight |
| Permissions used | container.clusters.list · container.clusters.get |
Where it applies
Why Google steers node pools to Container-Optimized OS
GKE Standard lets you choose the node operating system per pool. Google’s
node image guide is clear
about its preference: Container-Optimized OS with containerd (cos_containerd) is the
recommended node OS, and Autopilot clusters always use it. The same page describes the images as
optimised to enhance node security and backed by a Google team that can quickly patch them, and
states they provide better support, security and stability than the other images.
Ubuntu is supported and validated, and Google names the cases for it: nodes that need XFS, CephFS or Debian packages. Outside those cases, a general-purpose distribution on nodes is more software to patch without a reason to have it.
Listing image types per pool
gcloud container node-pools list --cluster=CLUSTER_NAME --location=LOCATION \ --format="table(name,config.imageType)"Which pools ZopNight flags
ZopNight reads each node pool’s image type from inventory. A value of COS or COS_CONTAINERD
is compliant; any other value, including Ubuntu and Windows images, raises a finding that names
the image in use. A pool with no recorded image type is skipped.
Cases that deserve an exception
Windows containers need Windows Server nodes, so a Windows Server LTSC (windows_ltsc_containerd) pool is flagged
even though it cannot move to Container-Optimized OS. Treat those findings as documented
exceptions. The same applies to Ubuntu pools that exist for one of Google’s named reasons, or for
a DaemonSet that installs kernel modules or host packages.
Security posture only
There is no saving attached to this finding. The concern is attack surface and how quickly the node OS receives fixes.
Moving a pool to Container-Optimized OS
- Check workloads for host dependencies: privileged DaemonSets that install packages, hostPath mounts of distribution-specific paths, or kernel modules.
- Test on a new small pool first:
gcloud container node-pools create cos-test --cluster=CLUSTER_NAME --location=LOCATION --image-type=COS_CONTAINERD --num-nodes=1. - Switch the pool:
gcloud container clusters upgrade CLUSTER_NAME --location=LOCATION --image-type=COS_CONTAINERD --node-pool=POOL_NAME. - Watch Pods reschedule onto the new nodes.