Workbench notebooks running with Shielded VM Secure Boot off
What does ZopNight detect here?
Secure Boot verifies boot-chain signatures before a Workbench VM starts, blocking rootkits and bootkits that load below the OS. ZopNight flags notebooks whose secureBoot metadata reads false (a positive signal, never an assumption), and the fix costs $0: stop the instance, enable the checkbox alongside vTPM and integrity monitoring, restart.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1236 |
| Category | security |
| Severity | low |
| Metric | none — pure configuration read |
| Source | vertex_security.go |
Where it applies
What boots before the OS
Secure Boot has the UEFI firmware verify the signature of each stage of the boot chain before executing it, which is the only layer that catches malware loading below the operating system: rootkits and bootkits that a runtime scanner never sees. Workbench notebooks run on Shielded VM-capable machines, but Secure Boot is frequently switched off at creation, most often because a custom GPU driver or unsigned kernel module refused to load during setup and disabling the check was the fastest unblock.
A positively-recorded false
The rule consumes the discoverer’s secureBoot stamp and fires only when it reads
exactly false. Absent metadata means the boot posture was never resolved, and the rule
skips rather than infers, the same fail-safe posture as every data-only check in this
family. Severity is low: this is hardening, not an exposed port, and it carries no
dollar figure because there is nothing to save, only risk to remove.
Enablement requires a stop
Shielded VM settings cannot change on a running instance. The sequence is stop, enable
Secure Boot, restart, a maintenance window of minutes. The stop/start pair is covered by
notebooks.instances.stop and notebooks.instances.start in roles/notebooks.admin.
If the instance needed unsigned kernel modules, that surfaces immediately on the first
boot: the module fails to load, and the honest choices are a signed build of the module
or a documented exception, not a silent permanent opt-out.
Query the shielded config
gcloud workbench instances describe my-notebook --location us-central1-a \ --format="value(gceSetup.shieldedInstanceConfig.enableSecureBoot)"A false or empty result reproduces the finding on that instance.
Paired protections worth enabling together
Secure Boot is one of three Shielded VM switches; vTPM and integrity monitoring are the other two, and the console exposes them side by side in the same stopped-instance edit. Enabling all three in the one window costs nothing extra and gives the integrity dashboard a baseline to alert against, so the fleet-wide pass this rule motivates should flip the trio, not just the flagged bit.