Skip to main content

More Info:

Use Container-Optimized Os (Cos) As A Managed, Optimized And Hardened Base Os That Limits The HostS Attack Surface.

Risk Level

High

Address

Security

Compliance Standards

  • APRA CPS 234 (Australia)
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS Critical Security Controls v8
  • CIS GKE
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • Essential 8
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIS2 Directive
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • UK NCSC Cyber Assessment Framework

Triage and Remediation

Remediation

Manual Steps

  1. List all clusters and node pools using non-COS images
    • Run on: any machine with gcloud and project access.
    • Identify node pools where config.imageType is not cos_containerd.
  2. Confirm workloads and constraints that might prevent migration
    • For each affected cluster, list Pods and note any privileged/host-level requirements:
    • Review whether any workloads rely on OS-specific features or custom images incompatible with COS.
  3. Review autoscaling, maintenance windows, and disruption impact
    • Check node pool size and autoscaling to understand rolling upgrade impact:
    • Decide whether a rolling upgrade is acceptable now or requires a maintenance window.
  4. Plan the change and, if acceptable, update node pools to cos_containerd
    • For each node pool you decide to migrate:
    • This triggers a rolling node replacement; pods will be rescheduled and may be briefly disrupted if PodDisruptionBudgets/replicas are insufficient.
  5. Verify the node pools now use cos_containerd
    • Re-run the audit on each updated node pool:
    • Confirm the output is "cos_containerd".
  6. Document exceptions where COS cannot be used
    • If you determine COS is not suitable for a specific node pool (due to workload or vendor constraints), record:
      • Cluster and node pool name.
      • Current image type and reason COS is not viable.
      • Compensating controls (e.g., hardened custom image, additional host security tooling).
    • Keep this documentation with your risk register and security exceptions for future review.
kubectl cannot change the GKE node image or OS type, because this is managed at the GKE control-plane / node pool configuration level via gcloud, console, or IaC. To remediate this finding, follow the guidance in the Manual Steps section using the Google Cloud provider tools.
Explanation of what indicates a problem:
  • In the “HUMAN-READABLE SUMMARY” table, any row where:
    • IMAGE_TYPE is not cos_containerd, and therefore
    • COMPLIANT is NO
    represents a node pool that does not meet CIS GKE 5.5.1 and should be reviewed.
  • In the JSON summary, any object with "compliant": false has an imageType other than cos_containerd and should be reviewed.

Additional Reading: