More Info:
Use Container-Optimized Os (Cos) As A Managed, Optimized And Hardened Base Os That Limits The HostS Attack Surface.Risk Level
HighAddress
SecurityCompliance 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
Remediation
Manual Steps
Manual Steps
-
List all clusters and node pools using non-COS images
- Run on: any machine with
gcloudand project access.
- Identify node pools where
config.imageTypeis notcos_containerd.
- Run on: any machine with
-
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.
-
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.
-
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.
-
Verify the node pools now use cos_containerd
- Re-run the audit on each updated node pool:
- Confirm the output is
"cos_containerd".
-
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.
- If you determine COS is not suitable for a specific node pool (due to workload or vendor constraints), record:
Using kubectl
Using kubectl
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.
Automation
Automation
-
In the “HUMAN-READABLE SUMMARY” table, any row where:
IMAGE_TYPEis notcos_containerd, and thereforeCOMPLIANTisNO
-
In the JSON summary, any object with
"compliant": falsehas an imageType other thancos_containerdand should be reviewed.

