Skip to main content
compliance · gcp

Compute Engine instances running without Shielded VM protections

resource types
1
rule IDs covered
1
severity
medium

What does ZopNight detect here?

Shielded VM protections (Secure Boot, vTPM, integrity monitoring) defend against boot-level rootkits and firmware tampering. ZopNight rule RC-1203 flags enriched Compute Engine instances lacking a shielded_vm_enabled=true stamp, which the discoverer writes when at least 1 of the 3 protections is on. Enabling them requires stopping the VM first.

Signal and threshold

How ZopNight evaluates Compute Engine instances running without Shielded VM protections.
Field Value
Rule IDsRC-1203
Categorycompliance
Severitymedium
Metricnone — pure configuration read
Sourcevm_shielded.go

What the shielded_vm_enabled stamp actually attests

Precision matters on this one. The GCP discoverer inspects the instance’s shieldedInstanceConfig and writes shielded_vm_enabled=true when any of Secure Boot, vTPM, or integrity monitoring is on. That is an OR, not an AND. Rule RC-1203 then flags enriched instances that lack that true stamp, anchoring on the always-present purchase_type key so a resource the discoverer never enriched fails safe instead of firing. Two consequences follow. First, the rule infers “not shielded” from the absence of a true-only stamp rather than from an explicit false. Second, an instance with only Secure Boot on (vTPM and integrity monitoring both off) counts as compliant and never fires, a documented producer-side looseness that a rule change cannot tighten.

Why boot-level integrity is worth a finding

Shielded VM is GCP’s defence against the class of attack that survives a rebuild: bootkits and kernel-level rootkits that persist below the OS. Secure Boot refuses unsigned boot components; the vTPM gives the instance measured boot and a sealed key store; integrity monitoring compares each boot’s measurements against a baseline and raises a Cloud Monitoring signal when they diverge. None of it protects a running workload from an application-level compromise. The value is knowing the platform underneath was not silently altered.

Inspect a flagged instance

Terminal window
gcloud compute instances describe my-vm --zone us-central1-a \
--format='value(shieldedInstanceConfig)'

Turning it on is a stop-start operation

The Shielded VM options can only be changed while the instance is stopped, so remediation costs a restart window. Order matters, too: enable vTPM and integrity monitoring broadly, but treat Secure Boot with care on VMs that load unsigned kernel modules, since third-party drivers and some older images will refuse to boot with it on. The image must also support UEFI; most current Google-provided images do, imported legacy images may not.

Preventing new unshielded VMs

Per-instance cleanup does not stop tomorrow’s terraform apply from creating another finding. The org policy constraint compute.requireShieldedVm blocks non-shielded instance creation across a project, folder, or the organization. Enforce it once and this rule’s backlog stops growing.

See it fire on your bill.

Connect an account read-only. The first findings land in minutes.

417 rule families across 353 resource types on 22 platforms. Every threshold, metric, and IAM action is documented on these pages before you grant anything.

417 rule families documented
353 resource types covered
read-only default access level
Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console· Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console·