Compute Engine VMs with Secure Boot, vTPM and integrity monitoring all off
What does ZopNight detect here?
Compute Engine VMs are flagged when none of the three Shielded VM options in `shieldedInstanceConfig` is on: Secure Boot, the virtual TPM and integrity monitoring. Those options verify the boot chain and record measurements, so a VM without any of them has no defence or evidence against rootkits and bootkits that persist across reboots.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1203 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Threshold | no Shielded VM option enabled |
| Source | ZopNight |
| Permissions used | compute.instances.list · compute.instances.get |
Where it applies
What each Shielded VM option guards against
Shielded VM bundles three controls. Secure Boot checks the signature of every boot component and halts the boot if one fails, which stops many bootkits and rootkits. The virtual Trusted Platform Module (vTPM) holds keys and supports Measured Boot, which hashes each boot stage. Integrity monitoring compares those measurements with a known-good baseline and reports when they drift.
With all three off, a compromised kernel or bootloader leaves no trace in the platform’s own records. Compliance frameworks that ask for verified boot integrity have nothing to point at.
Reading the three flags for your fleet
Each option is a separate boolean on the instance:
gcloud compute instances list --format="table( name, zone, shieldedInstanceConfig.enableSecureBoot, shieldedInstanceConfig.enableVtpm, shieldedInstanceConfig.enableIntegrityMonitoring)"A row where all three are false or empty is what this rule targets.
The condition that triggers it
ZopNight records whether each Compute Engine instance has Shielded VM protection during inventory, and treats an instance as protected when any one of the three options is on. The rule fires when none is. An instance that was not fully inventoried is skipped.
What the rule does not judge
Because one option is enough to count as protected, a VM with only vTPM and integrity monitoring on is not flagged even though Secure Boot is off. That gap is common in practice, because Google notes that Compute Engine does not enable Secure Boot by default, because unsigned drivers and other low-level software might not be compatible. Use the table above if your policy requires all three.
Hardening with no price tag
This is a compliance rule with a $0 saving. The practical cost of fixing it is a short stop and start of the VM.
Enabling the options on an existing VM
Google’s procedure requires a stop, the change, then a start:
gcloud compute instances stop VM_NAME --zone=ZONEgcloud compute instances update VM_NAME --zone=ZONE --shielded-vtpm --shielded-integrity-monitoring --shielded-secure-bootgcloud compute instances start VM_NAME --zone=ZONE- Watch the first boot. If it fails, stop the VM, rerun step 2 with
--no-shielded-secure-bootand start again.