Checks

Compute Engine VMs are evaluated for the metadata key block-project-ssh-keys set to true, indicating project-wide SSH keys are blocked and only instance-level or OS Login credentials are honored.

Google Compute Engine VMs configured as Confidential VMs encrypt data in use with hardware-based memory protection and per-instance keys.

This assessment identifies whether Confidential Computing is enabled on each VM instance.

Compute Engine VMs are evaluated for use of the default service account ([PROJECT_NUMBER]-compute@developer.gserviceaccount.com). The finding highlights instances configured with that account rather than a workload-specific service account. GKE node VMs are ignored.

Compute Engine VM instances using the default service account with the cloud-platform scope (Allow full access to all Cloud APIs) are identified. GKE nodes are excluded.

This check verifies whether GCP Compute Engine VM instances have deletion protection enabled to prevent accidental termination of production or critical workloads.

This check verifies whether GCP Compute Engine VM instances have auto-delete disabled for their attached persistent disks.

When auto-delete is enabled, persistent disks are automatically removed when the associated VM instance is deleted, which can lead to unintended data loss.

Compute Engine VM disks use Customer-Supplied Encryption Keys (CSEK) rather than provider-managed keys. The finding flags instances where any attached disk is not protected with the customer-provided key.

Managed Instance Groups (MIGs) should have autohealing enabled with a valid health check configured. Autohealing automatically recreates unhealthy instances based on application-level health checks, ensuring continuous availability.

Managed Instance Groups (MIGs) should be attached to load balancers via backend services to enable traffic distribution across instances. Load balancers provide health checking, autoscaling integration, and high availability features that are essential for production workloads.

Managed Instance Groups (MIGs) should be configured for multi-zone deployments to ensure high availability and fault tolerance. A multi-zone MIG distributes instances across multiple zones within a region, protecting applications from zonal failures.

Compute Engine VM instances with canIpForward enabled are identified. This setting allows a VM to process packets not addressed to its own IP.

Instances created by GKE (gke- prefix) are excluded from this evaluation.

Compute Engine VM instances should have their On Host Maintenance setting configured to MIGRATE for live migration during host maintenance events, ensuring continuous availability without downtime.

This check verifies that VM instances are not configured as preemptible or Spot VMs.

Both preemptible and Spot VMs can be terminated by Google at any time when resources are needed elsewhere, making them unsuitable for production and business-critical workloads. Spot VMs are the newer version of preemptible VMs and are Google's recommended approach for interruptible workloads.

Compute Engine VM instances with an assigned external (public) IP address on any network interface are identified.

Instances without an external IP are considered internal-only.

Compute Engine VM instance with the interactive serial console enabled via metadata serial-port-enable (1/true). Instances with this flag disabled do not allow interactive serial console connections.

Compute Engine VM instances have vTPM and Integrity Monitoring enabled as part of Shielded VM configuration.

VM instances should be configured with only one network interface unless multiple interfaces are explicitly required for complex network configurations.

Multiple network interfaces expand the attack surface and create additional network pathways that may be exploited.

This check identifies VM instances in a SUSPENDED or SUSPENDING state with persistent disks still attached.

Persistent disks on suspended VMs remain accessible through the GCP API and could contain sensitive data while the instance is inactive, potentially creating security blind spots in long-forgotten infrastructure.

Application Load Balancer (HTTP/S) backend services have Cloud Logging for requests enabled at the backend service level.

Only load balancers with a backend service support this setting.

Projects are assessed for a VPC network named default (the pre-created, auto-mode network).

VPC networks are assessed for a DNS policy that enables Cloud DNS query logging. When present, resolvers record queries for the network from VMs, GKE, peering, and inbound forwarding, with entries written to Cloud Logging.

Google Cloud networks are evaluated for legacy mode (subnet_mode: legacy). The finding highlights networks using the older, non-subnetted design instead of VPC with regional subnets.

OS Login Two-Factor Authentication (2FA) requires users to verify their identity with a second factor when connecting via SSH to VM instances.

This provides an additional security layer beyond passwords or SSH keys, significantly reducing the risk of unauthorized access even if credentials are compromised.

Project metadata has OS Login enabled (enable-oslogin), so VM SSH access uses IAM-linked Linux identities instead of static project or instance keys.