Use Patch to apply operating system patches across a set of Compute Engine VM instances (VMs). Long running VMs require periodic system updates to protect against defects and vulnerabilities.
The Patch feature has two main components:
- Patch compliance reporting, which provides insights on the patch status of your VM instances across Windows and Linux distributions. Along with the insights, you can also view recommendations for your VM instances.
- Patch deployment, which automates the operating system and software patch update process. A patch deployment schedules patch jobs. A patch job runs across VM instances and applies patches.
Benefits
The Patch service gives you the flexibility to complete the following processes:
- Create patch approvals. You can select what patches to apply to your system from the full set of updates available for the specific operating system.
- Set up flexible scheduling. You can choose when to run patch updates (one-time and recurring schedules).
- Apply advanced patch configuration settings. You can customize your patches by adding configurations such as pre and post patching scripts.
- Manage these patch jobs or updates from a centralized location. You can use the the Patch dashboard for monitoring and reporting of patch jobs and compliance status.
Pricing
For information about pricing, see VM Manager pricing.
How Patch works
To use the Patch feature, you must set up the OS Config API and install the OS Config agent. For detailed instructions, see Setting up VM Manager. The OS Config service enables patch management in your environment while the OS Config agent uses the update mechanism for each operating system to apply patches. Updates are pulled from the package repositories (otherwise called the distribution source package) or a local repository for the operating system.
The following update tools are used to apply patches:
- Red Hat Enterprise Linux (RHEL), Rocky Linux and CentOS -
yum upgrade - Debian and Ubuntu -
apt upgrade - SUSE Linux Enterprise Server (SLES) -
zypper update - Windows - Windows Update Agent
Patch and package sources
To use the Patch feature in VM Manager, the VM must have access to the package updates or patches. The Patch service does not host or maintain package updates or patches. In some scenarios your VM might not have access to the updates. For example, if your VM doesn't use public IPs or you are using a private VPC network. In these scenarios, you must complete additional steps to allow access to the updates or patches. Consider the following options:
- Google recommends hosting your own local repository or a Windows Server Update Service for full control over the patch baseline.
- Alternatively, you can make external update sources available to your VMs by using Cloud NAT or other proxy services.
Patch management consist of two services: patch deployment and patch compliance. Each service is explained in the following sections.
Patch deployment overview
A patch deployment is initiated by making a call to the VM Manager API (also known as the OS Config API). This can be done by using either the Google Cloud console, Google Cloud CLI, or a direct API call. Then the VM Manager API notifies the OS Config agent that is running on the target VMs to start patching.
The OS Config agent runs the patching on each VM by using the patch management
tool that is available for each distribution. For example, Ubuntu VMs use the
apt utility tool. The utility tool retrieves updates (patches) from
the distribution source for the operating system. As patching proceeds, the OS
Config agent reports the progress to the VM Manager API.
Patch compliance overview
After you set up the VM Manager on a VM, the following takes place on the VM:
- The OS Config agent periodically (about every 10 minutes) reports OS inventory data .
- The patch compliance backend periodically reads this data, cross references it with the package metadata obtained from the OS distribution and saves it.
- The Google Cloud console then gets the patch compliance data and displays this information in the console.
How patch compliance data is generated
The patch compliance backend periodically completes the following tasks:
- Reads the reports that are collected from OS inventory data on a VM.
Scans for classification data from the vulnerability source for each operating system, and orders this data based on severity (from highest to lowest).
The following table summarizes vulnerability source that is used for each operating system.
Operating system Vulnerability source package RHEL and CentOS https://access.redhat.com/security/data Debian https://security-tracker.debian.org/tracker Ubuntu https://launchpad.net/ubuntu-cve-tracker SLES N/A Patch compliance reporting is not supported on SLES
Rocky Linux N/A Patch compliance reporting is supported on Rocky Linux. However, the classification of vulnerability data based on severity is not available.
Windows The patch compliance backend gets the classification data from the Windows Update Agent API. Maps these classifications (provided by the vulnerability source) to Google's patch compliance status.
The following table summarizes the mapping system used to generate Google's patch compliance status.
Distribution source categories Google's patch compliance status - Critical
- Urgent
- WINDOWS_CRITICAL_UPDATE
Critical (RED) - Important
- High
- WINDOWS_SECURITY_UPDATE
Important/Security (ORANGE) - Everything else
Other (YELLOW) - No updates available
Up-to-date (GREEN) Selects the highest severity data for each available update and shows it on the Google Cloud console dashboard page. You can also see a full report of all available updates for the VM on the VM details page.
For example, if the OS inventory data for a RHEL 7 VM has the following package data:
- Package name: package1
- Installed Version: 1.4
- Update Version: 2.0
The patch compliance backend scans for classification data (from the source distribution) and retrieves the following information:
- Version 1.5 => Critical, fixes CVE-001
- Version 1.8 => Low, fixes CVE-002
- Version 1.9 => Low, fixes CVE-003
Then on the Google Cloud console dashboard, this RHEL 7 VM is then added to
list of VMs that have a Critical update available. If you review the details
for this VM, you see 1 Critical update available (version 2.0) with 3 CVE's,
CVE-001, CVE-002 and CVE-003.
Simultaneous patching
When you initiate a patch job, the service uses the instance filter you provided to determine the specific instances to be patched. Instance filters allow you to simultaneously patch many instances at the same time. This filtering is done when the patch job starts to account for changes in your environment after the job is scheduled.
Scheduled patching
Patches can be executed on demand, scheduled in advance, or configured with a recurring schedule. You can also cancel an in-progress patch job if you need to stop it immediately.
You can set up patch maintenance windows by creating patch deployments with a specified frequency and duration. Scheduling patch jobs with a specified duration ensures that patching tasks do not start outside of your designated maintenance window.
You can also enforce patch installation deadlines by creating patch deployments to be completed at a specific time. If targeted VMs are not patched by this date, then the scheduled deployment starts installing patches on this date. If VMs are already patched no action is taken on those VMs, unless a pre or post patch script is specified or a reboot is required.
What is included in a patch job?
When a patch job runs on a VM, depending on the operating system, a combination of updates are applied. You can choose to target specific updates, packages, or, for Windows operating systems, specify the KB IDs that you want to update.
You can also use a patch job to update any Google agents that are installed
as a standard package for that specific distribution. Use the update tool for
that distribution to query the packages that are available. For example, to see
the available Google agents for an Ubuntu operating system, run
apt list --installed | grep -P 'google'.
Windows
For Windows operating system, you can apply all or select from the following updates:
- Definition updates
- Driver updates
- Feature pack updates
- Security updates
- Tool updates
RHEL/Rocky/CentOS
For Red Hat Enterprise Linux, Rocky Linux and CentOS operating systems, you can apply all or select from the following updates:
- System updates
- Security updates
Debian/Ubuntu
For Debian and Ubuntu systems, you can apply all or select from the following updates:
- Distribution updates
- Package manager updates
SUSE
For SUSE Enterprise Linux Server (SLES) and openSUSE operating systems, you can apply all or select from the following updates:
- System package updates
- Zypper patches (specific bug fixes and security fixes)
Access patch summary for your VMs
To view the patch summary for your VMs, you have the following options:
To view the patch summary information for all VMs in an organization or folder, use the Patch dashboard on the Google Cloud console. See View patch summary for VMs.
To view the status of the patch jobs, use the Patch jobs page on the Google Cloud console. You can also use the Google Cloud CLI or the OS Config API. For more information, see Manage patch jobs.
To view other information such as OS package updates and vulnerability reports, see view operating system details.
The Patch dashboard
In the Google Cloud console, a dashboard is available that you can use to monitor the patch compliance for your VM instances.
Understanding the Patch dashboard
Operating system overview
This section reflects the total number of VMs, organized by operating system. For a VM to show up in this list, it must have the OS Config agent installed and OS inventory management enabled.
If a VM is listed with its operating system as No data, one or more of the
following scenarios might be true:
- The VM is unresponsive.
- OS Config agent is not installed.
- OS inventory management is not enabled.
The operating system is not supported. For a list of supported operating systems, see Supported operating systems.
Patch compliance status
This section provides details of the compliance status of each of the VMs organized by their operating system.
Compliance status are arranged in four main categories:
- Critical: This means that a VM has critical updates available.
- Important or security: This means that a VM has important or security updates available.
- Other: This means that a VM has updates available, but none of these updates are categorized as a critical or security update.
- Up-to-date: This means that a VM has no updates available.