Monday, February 17, 2025

What Is SLSA Tools In Google Cloud For Kubernetes Security

In this article let us discuss about GCE audit logs, What is SLSA, GKE Control Plane and GKE bolsters VM image verification with SLSA VSAs

What is included in your Kubernetes program? It’s essential to know where the software components you use come from in order to reduce risks and make sure your apps are reliable. You must understand your software supply chain in order to accomplish this.

As part of its ongoing efforts to improve software supply chain transparency, Google Cloud announced that SLSA, the Supply-chain Levels for Software Artifacts framework, may now be used to confirm the integrity of Google Kubernetes Engine components.

Software component integrity can be attested with the use of the SLSA set of standards. For GKE’s Container-Optimized OS (COS) virtual machine (VM) images, Google Cloud has started posting SLSA Verification Summary Attestations (VSAs) to GitHub. Additionally, Google Cloud has started routing GKE Kubernetes Control Plane GCE audit reports to client projects and improved Google Compute Engine (GCE) audit logs to include VM image IDs. This enables you to authenticate the virtual machine images used in your GKE clusters using SLSA VSAs.

GCE audit logs improvements

When an instance is formed from an image, the GCE image ID is now included in Google Compute Engine audit logs in records pertaining to instance creation activities (such insert, bulk insert, and update actions). Because every image instance has a distinct, unchangeable ID, you can track down the exact picture that was used to start each instance even if an image is erased and then regenerated with the same name.

When utilising the SLSA VSAs outlined below to confirm the picture’s provenance and integrity, the ID is utilised to uniquely identify the image. For security and regulatory reasons, this can offer a priceless audit trail.

Under used Resources in the metadata field, Google Cloud included a new attach Disks field that, for attached discs, stores the source image name, source image id, and whether or not it was used as the boot disc. With a search like this, you may locate this data in the Logs Explorer:

<div><br class=”Apple-interchange-newline”>resource.type=”gce_instance” ANDprotoPayload.methodName=”v1.compute.instances.insert”</div>

resource.type="gce_instance" ANDprotoPayload.methodName="v1.compute.instances.insert"
GCE instance insert audit log record with VM image id field
Image credit to Google Cloud

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

The Control Plane GCE audit logs for insert, bulk insert, and update operations, as well as the Shielded VM integrity logs, are now sent to the client project hosting the GKE cluster by new GKE clusters running version 1.29 or later.

Control Plane VM instance log entries may be recognised by their new metadata field. Use a log explorer query such as this to inspect the logs:

resource.type="gce_instance" AND (jsonPayload.metadata.isKubernetesControlPlaneVM="true" OR protoPayload.metadata.isKubernetesControlPlaneVM="true")

To help you identify which cluster the virtual machines (VMs) in the forwarded log records belong to in the event that you have multiple clusters for a project, Google Cloud has also added a new parentResource map under metadata to the forwarded logs. This map has two fields: parentResourceType, which has the value “gke_cluster,” and parentResourceId, which has the cluster hash as a value.

This improvement improves your ability to audit and safeguard your GKE clusters by giving you insight into the VM images used to build the Control Plane VMs as well as the instances’ integrity state.

KCP VM instance audit log record forwarded to customer project
Image credit to Google Cloud

GKE bolsters VM image verification with SLSA VSAs

The release of SLSA Verification Summary Attestations (VSAs) for GKE Container Optimised OS (COS) based virtual machine images is a major advancement in supply chain security for Google Kubernetes Engine (GKE). The GitHub repository for Google Cloud GKE VSA contains these attestations. This project can assist guarantee that the GKE VM images you’re using are authentic, unaltered, and come from a reliable source by offering you cryptographic evidence of their provenance and integrity.

To find a VSA for your GKE VM instances’ COS VM image. Examine the following folders located at the GitHub repository’s root:

  • VSAs for the Kubernetes control plane virtual machine images are located in the gke-master-images:78064567238 folder.
  • The VSAs for the node VM images are located in the gke-node-images:238739202978 folder.

You may find the corresponding VSA by using the image ID that can be located in the audit logs. For instance, the VSA for the node VM image with the id 3031893369549136349 is gke-node-images:238739202978/gke-12811-gke1044000-cos-109-17800-218-52-c-pre:3031893369549136349.intoto.jsonl.

Independent verification with slsa-verifier

The open-source slsa-verifier utility allows you to independently confirm the legitimacy of GKE VM images. By combining the GCE image name and ID, the VSA, and Google’s VSA public signing key, this tool enables you to verify the integrity of your GKE VM images.

The public key is

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEeGa6ZCZn0q6WpaUwJrSk+PPYEsca
3Xkk3UrxvbQtoZzTmq0zIYq+4QQl0YBedSyy+XcwAMaUWTouTrB05WhYtg==
-----END PUBLIC KEY-----

To verify a VM image use slsa-verifier as follows

<div><br class=”Apple-interchange-newline”>slsa-verifier verify-vsa \ <br></div>

slsa-verifier verify-vsa \
  --attestation-path "${VSA_PATH}" \
  --resource-uri gce_image://${VM_IMAGE_PROJECT_NAME}:${VM_IMAGE_NAME} \
  --subject-digest gce_image_id:${VM_IMAGE_ID} \
  --verifier-id https://bcid.corp.google.com/verifier/bcid_package_enforcer/v0.1 \
  --verified-level BCID_L1 \
  --verified-level SLSA_BUILD_LEVEL_2 \
  --public-key-path "${KEY_PATH}" \
  --public-key-id keystore://76574:prod:vsa_signing_public_key

where

  • The path to the VSA file is VSA_PATH.
  • The project name that houses the virtual machine image is VM_IMAGE_PROJECT_NAME (e.g., gke-node-images).
  • The image name, such as gke-12811-gke1044000-cos-109-17800-218-52-c-pre, is denoted by VM_IMAGE_NAME.
  • The image ID, such as 30318933695491363493, is denoted by VM_IMAGE_ID.
  • The path to the stored public key is KEY_PATH.

What is SLSA?

SLSA is an industry-wide collection of supply chain security principles that may be adopted gradually. Both software manufacturers and users may benefit from the standards established by SLSA: manufacturers can use SLSA’s guidelines to improve the security of their software supply chain, while consumers can use SLSA to choose whether to trust a software package.

SLSA provides

  • A standard vocabulary for discussing the security of software supply chains
  • A method of safeguarding your incoming supply chain by assessing the reliability of the artifacts you use
  • A practical guide to enhancing the security of your own software
  • A means to gauge your progress in adhering to the Secure Software Development Framework’s (SSDF) upcoming Executive Order requirements

Why SLSA is needed

The type of supply chain integrity flaws that may go unreported but, when exploited, soon become very visible, disruptive, and expensive in this context have been made public by high-profile assaults like those against SolarWinds and Codecov. They have also demonstrated that there are inherent dangers in the code itself as well as at various stages of the intricate software supply chain process that involves integrating the code into software systems. As confirmed by the U.S. Executive Order on Improving the Nation’s Cybersecurity, a common architecture for hardening the software supply chain is required because these threats are increasing and don’t appear to be slowing down.

Although crucial, security methods for source code analysis and vulnerability identification are insufficient on their own. Code modifications may occur even after fuzzing or vulnerability screening is finished, either accidentally or as a result of insider threats or compromised accounts. Every stage of a normal software supply chain, from source to build to packaging and delivery, has some risk of code alteration. Any flaws in the supply chain make it harder to trust that the code you execute is the same code you scanned.

No matter how complicated the software supply chain is, SLSA is intended to provide automation that monitors code handling from source to binary, guarding against manipulation. As a consequence, SLSA boosts confidence that the binary used following the build and distribution process is still subject to the analysis and review done on the source code.

How SLSA works

Google Cloud discuss SLSA in terms of levels and tracks. An SLSA track, like the Build Track, concentrates on a specific facet of a supply chain. Although SLSA v1.0 only has one track (Build), further iterations will include tracks that address additional aspects of the software supply chain, such source code management.

Ascending levels inside each track signify ever more stringent security procedures. Although they come with greater implementation costs, higher levels offer stronger protections against supply chain hazards. Although they offer only limited security assurances, lower SLSA levels are intended to be simpler to implement. Software that does not yet fulfil any SLSA level is occasionally referred to as having SLSA 0. Although Levels 1 through 3 are now included in the SLSA Build Track, Google Cloud anticipate that future upgrades will allow for higher levels.

Tracks and levels together provide a simple means of discussing whether software satisfies a given set of criteria. For instance, by stating that an artifact satisfies SLSA Build Level 3, you are conveying in a single sentence that the software artifact was developed in accordance with a set of security procedures that are acknowledged by industry leaders to guard against certain supply chain breaches.

Who is SLSA for?

In a nutshell: everyone who creates, uses, or supplies software infrastructure.

A software vendor, an open source initiative, or a group of people creating first-party code for internal use are examples of software producers. By lowering insider risk and boosting assurance that the software you create reaches your customers as intended, SLSA protects you from manipulation along the supply chain to your customers.

A government agency utilising vendored software, a development team using open source packages, or a CISO assessing organisational risk are examples of software consumers. With the help of SLSA, you may evaluate the security procedures of the software you depend on and make sure that what you get meets your expectations.

Infrastructure suppliers are companies that offer infrastructure like build platforms, CI/CD platforms, and ecosystem package managers. Your implementation of SLSA facilitates a secure software supply chain between manufacturers and consumers by acting as a bridge between them.

Thota nithya
Thota nithya
Thota Nithya has been writing Cloud Computing articles for govindhtech from APR 2023. She was a science graduate. She was an enthusiast of cloud computing.
RELATED ARTICLES

Recent Posts

Popular Post

Govindhtech.com Would you like to receive notifications on latest updates? No Yes