5.5.1 Use COS_CONTAINERD node images for GKE node pools

Information

Use COS_CONTAINERD node images for GKE node pools unless there is a specific workload requirement for Ubuntu or Windows. COS_CONTAINERD provides Container-Optimized OS with containerd, giving GKE nodes a Google maintained operating system image that is built, optimized, and hardened for running containers.

Container-Optimized OS is recommended for GKE nodes because it is designed specifically for container workloads, has a smaller operating system footprint, and is maintained by Google for GKE node security, stability, and support. Using COS_CONTAINERD helps reduce the node host attack surface and avoids unnecessary host level packages or services that are not required to run Kubernetes workloads.

COS_CONTAINERD uses containerd as the container runtime directly integrated with Kubernetes. Containerd is used by all current GKE node images and is considered more resource efficient and secure than the older Docker runtime. Workloads and operational tooling should not depend on Docker Engine access on the node.

Solution

Update noncompliant GKE node pools to use COS_CONTAINERD unless there is a documented requirement for Ubuntu or Windows node images. This remediation changes the node image for the selected node pool and should be planned as a node pool upgrade activity.

gcloud container clusters upgrade $CLUSTER_NAME \\
--location=$LOCATION \\
--project=$PROJECT_ID \\
--node-pool=$NODE_POOL \\
--image-type=COS_CONTAINERD

After the upgrade completes, rerun the audit command and verify that the node pool reports COS_CONTAINERD . Validate workloads before and after the change, especially anything that depends on host level packages, Ubuntu specific behavior, Windows nodes, or Docker Engine access.

Impact:

Changing an existing node pool to COS_CONTAINERD requires a node image upgrade, which can be a long running operation. Validate workloads and operational tooling before the change, especially anything that expects Ubuntu specific packages, direct host customization, third party kernel modules, Docker Engine access, or Docker based troubleshooting workflows. Use containerd compatible tools and Kubernetes native operational patterns instead of interacting with Docker directly on the node.

See Also

https://workbench.cisecurity.org/benchmarks/24956