How Does Container Optimized OS Handle Security Updates?

9/14/2018

If there is a security patch for Google's Container Optimized OS itself, how does the update get applied?

Google's information on the subject is vague

https://cloud.google.com/container-optimized-os/docs/concepts/security#automatic_updates

Google claims the updates are automatic, but how?

  • Do I have to set a config option to update automatically?
  • Does the node need to have access to the internet, where is the update coming from? Or is Google Cloud smart enough to let Container Optimized OS update itself when it is in a private VPC?
-- ilooner
google-cloud-platform
google-kubernetes-engine

2 Answers

11/6/2019

Do I have to set a config option to update automatically?

The automatic update behavior for Compute Engine (GCE) Container-Optimized OS (COS) VMs (i.e. those instances you created directly from GCE) are controlled via the "cos-update-strategy" GCE metadata. See the documentation at here.

The current documented default behavior is: "If not set all updates from the current channel are automatically downloaded and installed."

The download will happen in the background, and the update will take effect when the VM reboots.

Does the node need to have access to the internet, where is the update coming from? Or is Google Cloud smart enough to let Container Optimized OS update itself when it is in a private VPC?

Yes, the VM needs to access to the internet. If you disabled all egress network traffic, COS VMs won't be able to update itself.

-- Xuewei Zhang
Source: StackOverflow

9/15/2018

When operated as part of Kubernetes Engine, the auto-upgrade functionality of Container Optimized OS (cos) is disabled. Updates to cos are applied by upgrading the image version of the nodes using the GKE upgrade functionality – upgrade the master, followed by the node pool, or use the GKE auto-upgrade features.


The guidance on upgrading a Kubernetes Engine cluster describes the upgrade process used for manual and automatic upgrades: https://cloud.google.com/kubernetes-engine/docs/how-to/upgrading-a-cluster.

In summary, the following process is followed:

  1. Nodes have scheduling disabled (so they will not be considered for scheduling new pods admitted to the cluster).

  2. Pods assigned to the node under upgrade are drained. They may be recreated elsewhere if attached to a replication controller or equivalent manager which reschedules a replacement, and there is cluster capacity to schedule the replacement on another node.

  3. The node's Computer Engine instance is upgraded with the new cos image, using the same name.

  4. The node is started, re-added to the cluster, and scheduling is re-enabled. (Besides some conditions, most pods will not automatically move back.)

This process is repeated for subsequent nodes in the cluster.


When you run an upgrade, Kubernetes Engine stops scheduling, drains, and deletes all of the cluster's nodes and their Pods one at a time. Replacement nodes are recreated with the same name as their predecessors. Each node must be recreated successfully for the upgrade to complete. When the new nodes register with the master, Kubernetes Engine marks the nodes as schedulable.

-- Cosmic Ossifrage
Source: StackOverflow