Jump to Content
Security & Identity

How we’re making GKE more transparent with supply-chain attestation and SLSA

January 24, 2025
Abdelfettah Sghiouar

Senior Cloud Developer Advocate

Elias Levy

Principal Engineer

Join us at Google Cloud Next

Early bird pricing available now through Feb 14th.

Register

What goes into your Kubernetes software? Understanding the origin of the software components you deploy is crucial for mitigating risks and ensuring the trustworthiness of your applications. To do this, you need to know your software supply chain.

Google Cloud is committed to providing tools and features that enhance software supply chain transparency, and today we're excited to announce that you can now verify the integrity of Google Kubernetes Engine components with SLSA, the Supply-chain Levels for Software Artifacts framework

SLSA is a set of standards that can help attest the integrity of software components. We’ve begun to publish SLSA Verification Summary Attestations (VSAs) for GKE’s Container-Optimized OS (COS) virtual machine (VM) images to GitHub. We’ve also enhanced Google Compute Engine (GCE) audit logs to include VM image identifiers, and begun to route GKE Kubernetes Control Plane GCE audit logs to customer projects. This allows you to use SLSA VSAs to authenticate the VM images used in your GKE clusters.

GCE audit logs improvements

Google Compute Engine audit logs now include the GCE image ID in records related to instance creation events (such as insert, bulk insert, and update operations) when an instance is created from an image. This allows you to trace the precise image used to launch each instance even if an image is deleted and recreated with the same name, as each image instance has a unique immutable ID. 

The ID is used to uniquely identify the image when verifying its provenance and integrity using the SLSA VSAs described below. This can provide an invaluable audit trail for security and compliance purposes.

We introduced a new attachDisks field, under usedResources in the metadata field, that for attached disks records the source image name, source image id, and whether it was used as the boot disk. You can find this information in the Logs explorer using a query like:

Loading...

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_65aDYAM.max-1400x1400.png

GCE instance insert audit log record with VM image id field

GKE Control Plane audit and integrity logs now forwarded to your project

New GKE clusters running version 1.29 or later now forward their Control Plane GCE audit logs records for insert, bulk insert, and update operations, and their Shielded VM integrity logs, to the customer project hosting the GKE cluster. 

You can identify Control Plane VM instance log records by the presence of a new metadata field. To view the logs use a log explorer query like:

Loading...

Additionally, we’ve added to the forwarded logs a new parentResource map under metadata with two fields, parentResourceType, with a value of “gke_cluster”, and parentResourceId, with the cluster hash as a value, so you can tell which cluster the VMs in the forwarded log records belong to in case you have more than one cluster per project.

This enhancement allows you to gain visibility into the VM images used to create the Control Plane VMs, and the integrity status of the instances, further strengthening your ability to audit and secure your GKE clusters.

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_R7NyYlw.max-1900x1900.png

KCP VM instance audit log record forwarded to customer project

GKE bolsters VM image verification with SLSA VSAs

Google Kubernetes Engine (GKE) is taking a significant step forward in supply chain security by publishing SLSA Verification Summary Attestations (VSAs) for GKE Container Optimized OS (COS) based VM images. These attestations are available in the Google Cloud GKE VSA GitHub repository. This initiative can provide you with cryptographic proof of the integrity and provenance of the GKE VM images you’re using, help ensure that they haven't been tampered with, and that they originate from a trusted source.

To locate a VSA for the COS VM image used in your GKE VM instances. Look in the folders at the root of the GitHub repository:

  • The folder gke-master-images:78064567238 contains VSAs for the Kubernetes control plane VM images.

  • The folder gke-node-images:238739202978 contains the VSAs for the node VM images.

Using the image ID found in the audit logs you can locate the matching VSA. For example, gke-node-images:238739202978/gke-12811-gke1044000-cos-109-17800-218-52-c-pre:3031893369549136349.intoto.jsonl is the VSA for the the node VM image with an id of 3031893369549136349.

Independent verification with slsa-verifier

You can independently verify the authenticity of GKE VM images using the open-source slsa-verifier tool. This tool allows you to validate the integrity of your GKE VM images by combining the GCE image name and ID, the VSA, and Google’s VSA public signing key.

The public key is

Loading...

To verify a VM image use slsa-verifier as follows:

Loading...

where

  • VSA_PATH is the path to the VSA file

  • VM_IMAGE_PROJECT_NAME is the name of the project hosting the VM image (e.g., gke-node-images)

  • VM_IMAGE_NAME is the image name (e.g., gke-12811-gke1044000-cos-109-17800-218-52-c-pre)

  • VM_IMAGE_ID is the image ID (e.g. 30318933695491363493)

  • KEY_PATH is the path to the saved public key

Next steps

These enhancements reflect Google Cloud's commitment to providing you with the tools and capabilities needed to help build and manage secure, transparent software supply chains. To learn more about how to verify the integrity of the GKE control plane check out the user guide. You can find more information on securing your GKE cluster in the documentation.

Posted in