{"id":635,"date":"2026-04-14T20:21:24","date_gmt":"2026-04-14T20:21:24","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-shielded-vm-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-compute\/"},"modified":"2026-04-14T20:21:24","modified_gmt":"2026-04-14T20:21:24","slug":"google-cloud-shielded-vm-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-compute","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-shielded-vm-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-compute\/","title":{"rendered":"Google Cloud Shielded VM Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Compute"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Compute<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Shielded VM is a security hardening capability for <strong>Google Cloud Compute Engine<\/strong> virtual machines that helps protect your instances from low-level attacks such as bootkits and rootkits.<\/p>\n\n\n\n<p>In simple terms: <strong>Shielded VM helps ensure your VM boots using trusted software<\/strong>, and it provides signals you can monitor if the VM\u2019s boot integrity changes unexpectedly.<\/p>\n\n\n\n<p>Technically, Shielded VM combines <strong>Secure Boot<\/strong>, a <strong>virtual Trusted Platform Module (vTPM)<\/strong>, and <strong>Integrity Monitoring<\/strong> to verify and measure the VM\u2019s boot process. These protections make it harder for attackers (or accidental misconfiguration) to persist malware \u201cbelow the OS,\u201d where traditional endpoint tools often have limited visibility.<\/p>\n\n\n\n<p>The main problem Shielded VM solves is <strong>boot-level compromise<\/strong>\u2014when the firmware\/bootloader\/kernel is modified to hide malicious activity, survive reboots, and evade detection.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Shielded VM?<\/h2>\n\n\n\n<p>Shielded VM is a set of security features for <strong>Compute Engine<\/strong> instances in <strong>Google Cloud<\/strong> designed to protect against threats that attempt to compromise the VM at boot time or modify the boot chain.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose (what Google Cloud positions it for)<\/h3>\n\n\n\n<p>Shielded VM is intended to:\n&#8211; <strong>Defend against boot-level and firmware-level malware<\/strong> (for example, bootkits\/rootkits).\n&#8211; <strong>Prevent untrusted code from executing during boot<\/strong> (when Secure Boot is enabled).\n&#8211; <strong>Provide integrity signals and measurements<\/strong> so you can detect unexpected changes and respond.<\/p>\n\n\n\n<p>Official docs: https:\/\/cloud.google.com\/compute\/shielded-vm\/docs<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<p>Shielded VM is primarily composed of:\n&#8211; <strong>Secure Boot<\/strong>: Verifies that boot components are signed and trusted before they run.\n&#8211; <strong>vTPM (virtual TPM)<\/strong>: A virtualized hardware trust module that can store keys and record measurements of the boot process.\n&#8211; <strong>Integrity Monitoring<\/strong>: Surfaces integrity-related signals so you can monitor and alert on boot integrity status.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Major components (conceptual view)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>UEFI firmware<\/strong> (used to support Secure Boot and measured boot capabilities)<\/li>\n<li><strong>Bootloader and kernel signature verification<\/strong> (Secure Boot path)<\/li>\n<li><strong>vTPM<\/strong> for protected storage and measured boot registers (PCRs)<\/li>\n<li><strong>Integrity reporting<\/strong> surfaced through Google Cloud tooling (Console; integrations vary\u2014verify in official docs for exact metric\/log names)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<p>Shielded VM is <strong>not a standalone product you deploy<\/strong>. It is a <strong>security feature of Compute Engine instances<\/strong> that you enable at instance creation (and manage through instance configuration\/APIs).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Scope (zonal\/regional\/project)<\/h3>\n\n\n\n<p>Shielded VM settings apply at the <strong>VM instance level<\/strong>, and since Compute Engine VMs are typically <strong>zonal resources<\/strong>, Shielded VM is effectively <strong>zonal per-instance configuration<\/strong> within a <strong>project<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Google Cloud ecosystem<\/h3>\n\n\n\n<p>Shielded VM is part of the broader Google Cloud compute security toolbox:\n&#8211; <strong>Compute Engine<\/strong> for VM workloads\n&#8211; <strong>Cloud IAM<\/strong> for access control to create\/modify instances and view integrity details\n&#8211; <strong>Cloud Monitoring \/ Logging<\/strong> for operational visibility and alerting (exact signals and where they appear can evolve\u2014verify in official docs)\n&#8211; Works alongside other security controls like:\n  &#8211; <strong>OS Login<\/strong> and <strong>IAM-controlled SSH access<\/strong>\n  &#8211; <strong>VPC firewall rules<\/strong>, <strong>Cloud NAT<\/strong>, and <strong>IAP TCP forwarding<\/strong>\n  &#8211; <strong>Confidential VM<\/strong> (different goal: memory encryption in use)\n  &#8211; <strong>Customer-managed encryption keys (CMEK)<\/strong> for disks (data-at-rest encryption control)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Shielded VM?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Reduce risk of high-impact compromise<\/strong>: Boot-level persistence is hard to detect and often leads to severe incidents.<\/li>\n<li><strong>Support compliance and audit expectations<\/strong>: Many security programs require stronger controls for platform integrity and tamper resistance.<\/li>\n<li><strong>Lower incident response cost<\/strong>: Better integrity signals can shorten investigation time.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Blocks or reduces boot-chain tampering<\/strong> with Secure Boot.<\/li>\n<li><strong>Adds measured boot signals<\/strong> with vTPM that can support attestation-style workflows.<\/li>\n<li><strong>Works at the compute layer<\/strong> (below the OS), complementing endpoint protection and OS hardening.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Standardize hardening<\/strong> for VM fleets (especially in MIGs).<\/li>\n<li><strong>Improves visibility<\/strong> into a class of issues that are otherwise opaque.<\/li>\n<li><strong>Integrates with infrastructure-as-code<\/strong> patterns (Terraform, deployment pipelines) via instance configuration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Helps address controls around:<\/li>\n<li>platform integrity<\/li>\n<li>secure configuration baselines<\/li>\n<li>detection of unauthorized changes<\/li>\n<li>Useful in regulated environments (finance, healthcare, public sector) where hardening and evidence matter.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Shielded VM is designed to be largely transparent to typical workloads.<\/li>\n<li>It scales with your fleet because it\u2019s configured per VM\/template and can be rolled out gradually.<\/li>\n<\/ul>\n\n\n\n<p>(Performance impact is workload- and configuration-dependent; verify in official docs and test in staging for latency-sensitive environments.)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose Shielded VM<\/h3>\n\n\n\n<p>Choose Shielded VM when:\n&#8211; You run <strong>internet-facing services<\/strong> on Compute Engine.\n&#8211; You operate <strong>multi-tenant<\/strong> or sensitive workloads.\n&#8211; You need <strong>higher confidence in boot integrity<\/strong>.\n&#8211; You want a <strong>default secure baseline<\/strong> for VM fleets.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Shielded VM may not be the right fit when:\n&#8211; Your workflow depends on <strong>custom kernels, unsigned bootloaders, or low-level drivers<\/strong> that are incompatible with Secure Boot.\n&#8211; You rely on OS images or special configurations that aren\u2019t compatible with Shielded VM features (verify supported images\/OSs).\n&#8211; You need protection for <strong>data-in-use memory<\/strong>; Shielded VM is not a substitute for <strong>Confidential VM<\/strong>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Shielded VM used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Financial services (payments, fraud systems, core banking services)<\/li>\n<li>Healthcare (PHI workloads on VMs)<\/li>\n<li>Retail\/e-commerce (checkout services, customer accounts)<\/li>\n<li>SaaS and B2B platforms (multi-tenant environments)<\/li>\n<li>Media and gaming (backend services requiring strong hardening)<\/li>\n<li>Government and education (baseline security and compliance)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering teams building secure VM blueprints<\/li>\n<li>SRE\/operations teams running large VM fleets<\/li>\n<li>Security engineering teams implementing hardening and detection<\/li>\n<li>DevOps teams building CI\/CD and golden image pipelines<\/li>\n<li>Compliance and audit teams requiring integrity controls<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Web\/API services (Nginx\/Envoy\/Java\/.NET workloads)<\/li>\n<li>VM-based Kubernetes nodes (when using VM node pools\u2014verify product specifics such as \u201cShielded GKE nodes\u201d in GKE docs)<\/li>\n<li>Bastion-less admin patterns using IAP + OS Login<\/li>\n<li>Legacy apps that require VMs but still need strong baseline security<\/li>\n<li>Data processing workers (batch) where fleet security matters<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Managed Instance Groups (MIGs) with hardened instance templates<\/li>\n<li>Blue\/green or canary deployments where hardening can roll out gradually<\/li>\n<li>Hybrid patterns (VPN\/Interconnect to on-prem) where VM integrity is critical<\/li>\n<li>Multi-project organizations enforcing guardrails (organization policy, IAM)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production<\/strong>: strong fit\u2014security baseline plus monitoring\/alerting.<\/li>\n<li><strong>Dev\/test<\/strong>: still valuable, especially for \u201cshift-left\u201d detection of image\/kernel changes. However, Secure Boot can break developer workflows that depend on custom kernels\/modules, so align with your engineering needs.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where Shielded VM commonly fits.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Secure baseline for all internet-facing Compute Engine VMs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Public endpoints are common targets; attackers may aim for persistence.<\/li>\n<li><strong>Why Shielded VM fits<\/strong>: Secure Boot and measured boot reduce the risk of stealthy boot-chain compromise.<\/li>\n<li><strong>Example<\/strong>: A public API service in a MIG uses Shielded VM across all instances, with alerts on integrity status changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Hardened managed instance groups (MIGs) for stateless services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Large fleets amplify the blast radius of an image compromise.<\/li>\n<li><strong>Why it fits<\/strong>: Shielded settings are configured in instance templates and applied consistently.<\/li>\n<li><strong>Example<\/strong>: A multi-zone MIG runs Shielded VM with Secure Boot enabled, updated via rolling replacements.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Secure \u201cgolden image\u201d pipelines<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Image supply chain issues can introduce boot-level tampering.<\/li>\n<li><strong>Why it fits<\/strong>: Secure Boot requires trusted signatures; integrity signals help validate images behave as expected.<\/li>\n<li><strong>Example<\/strong>: Packer builds images; the platform team validates Shielded VM integrity signals in staging before promoting images.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Compliance-driven workloads requiring stronger platform integrity evidence<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Auditors require evidence of platform hardening and integrity monitoring.<\/li>\n<li><strong>Why it fits<\/strong>: Shielded VM is a concrete compute-layer control with monitorable signals.<\/li>\n<li><strong>Example<\/strong>: PCI-scoped payment microservices on VMs use Shielded VM plus OS Login and centralized logging.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Protecting administrative jump workloads (without a traditional bastion)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Admin access targets are high value; boot compromise can steal credentials.<\/li>\n<li><strong>Why it fits<\/strong>: Shielded VM reduces boot-level persistence risk, while IAP reduces network exposure.<\/li>\n<li><strong>Example<\/strong>: Admin utility VM has no external IP; accessed only via IAP TCP forwarding and OS Login, with Shielded VM enabled.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Running third-party security agents with higher assurance<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Endpoint agents can be bypassed by low-level malware.<\/li>\n<li><strong>Why it fits<\/strong>: Shielded VM provides a stronger foundation and integrity signals below the OS layer.<\/li>\n<li><strong>Example<\/strong>: SOC requires EDR + Shielded VM for workloads handling customer data.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Multi-team shared projects where \u201cuntrusted\u201d images might be introduced<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Different teams can accidentally deploy misconfigured or risky OS images.<\/li>\n<li><strong>Why it fits<\/strong>: Shielded VM can be standardized; org policies can help enforce secure baselines (verify exact org policy constraints in official docs).<\/li>\n<li><strong>Example<\/strong>: A platform project only allows instance templates that enable Shielded VM.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Migration from on-prem secure boot\/TPM expectations to cloud VMs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: On-prem standards often require Secure Boot + TPM.<\/li>\n<li><strong>Why it fits<\/strong>: Shielded VM provides cloud equivalents (Secure Boot + vTPM).<\/li>\n<li><strong>Example<\/strong>: A regulated enterprise migrates app servers to Compute Engine and maps controls to Shielded VM.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Detecting unexpected boot changes after an incident<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: After an intrusion, teams need to know if boot integrity was affected.<\/li>\n<li><strong>Why it fits<\/strong>: Integrity Monitoring provides a signal trail (where available) and can be integrated into IR runbooks.<\/li>\n<li><strong>Example<\/strong>: An incident triggers a review of integrity status across affected VMs; compromised nodes are replaced.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Secure VM nodes for container clusters (VM-based nodes)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Node compromise undermines cluster security.<\/li>\n<li><strong>Why it fits<\/strong>: Shielded VM helps protect node boot integrity.<\/li>\n<li><strong>Example<\/strong>: A cluster uses Shielded VM-backed nodes; node pools roll out updates with integrity checks in monitoring.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Secure edge processing in DMZ-like VPC segments<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: DMZ workloads are exposed and frequently attacked.<\/li>\n<li><strong>Why it fits<\/strong>: Shielded VM adds defense-in-depth.<\/li>\n<li><strong>Example<\/strong>: TLS termination proxies run on Shielded VMs with minimal inbound firewall rules.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) High-value license servers or control-plane components on VMs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Attackers target systems that can unlock broader access.<\/li>\n<li><strong>Why it fits<\/strong>: Boot-level protections reduce stealth persistence.<\/li>\n<li><strong>Example<\/strong>: A license server uses Shielded VM and strict IAM + OS Login; integrity status changes trigger paging.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>This section focuses on Shielded VM features that are generally documented as part of Compute Engine\u2019s Shielded VM offering. For the latest supported combinations (OS images, machine families, and exact behaviors), verify in official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Secure Boot<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Ensures the VM boots only using <strong>trusted, signed boot software<\/strong>. If the bootloader\/kernel components aren\u2019t trusted, the VM may fail to boot (by design).<\/li>\n<li><strong>Why it matters<\/strong>: Prevents a common persistence technique: altering the boot chain to load malware early.<\/li>\n<li><strong>Practical benefit<\/strong>: Strong preventative control against bootkits and some rootkits.<\/li>\n<li><strong>Limitations\/caveats<\/strong>:<\/li>\n<li>Can be incompatible with <strong>custom kernels<\/strong>, unsigned bootloaders, or certain drivers.<\/li>\n<li>Requires a compatible guest environment (often UEFI\/Gen2-style). Verify supported images and requirements.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">vTPM (Virtual Trusted Platform Module)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Provides a <strong>virtual TPM<\/strong> device for the VM. TPMs can securely store keys and record measurements (PCR values) of the boot chain.<\/li>\n<li><strong>Why it matters<\/strong>: TPM-backed measurements make tampering detectable and support stronger trust decisions.<\/li>\n<li><strong>Practical benefit<\/strong>: Enables measured boot signals and can support remote attestation patterns using Compute Engine APIs.<\/li>\n<li><strong>Limitations\/caveats<\/strong>:<\/li>\n<li>vTPM is not the same as a physical hardware TPM, but it provides similar primitives in a virtualized environment.<\/li>\n<li>Guest OS support varies; verify for your OS and image.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrity Monitoring<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Exposes <strong>boot integrity information<\/strong> so you can monitor whether the VM booted as expected.<\/li>\n<li><strong>Why it matters<\/strong>: Detection is the second half of defense-in-depth\u2014if something changes, you want to know quickly.<\/li>\n<li><strong>Practical benefit<\/strong>: Supports alerting and fleet visibility (for example, \u201cwhich VMs have unexpected boot changes?\u201d).<\/li>\n<li><strong>Limitations\/caveats<\/strong>:<\/li>\n<li>Integrity Monitoring primarily relates to <strong>boot-time integrity<\/strong>, not post-boot runtime compromise.<\/li>\n<li>How integrity events\/metrics are surfaced can evolve; verify current Cloud Monitoring\/Logging integration points in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Measured boot and PCR values (attestation building blocks)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Measures boot components into TPM PCRs. Compute Engine exposes an API to retrieve Shielded VM identity\/measurements (for attestation workflows).<\/li>\n<li><strong>Why it matters<\/strong>: Enables systems to make trust decisions (for example, allowing a VM to access sensitive resources only if it matches a known-good boot state).<\/li>\n<li><strong>Practical benefit<\/strong>: Can be used to build stronger admission controls for sensitive apps (custom integration required).<\/li>\n<li><strong>Limitations\/caveats<\/strong>:<\/li>\n<li>Remote attestation workflows require careful design: baselines, rotation, and false-positive handling.<\/li>\n<li>Not a turnkey \u201cattestation service\u201d; you build and operate the policy around it.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Instance configuration controls (per VM \/ per template)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Lets you enable\/disable Shielded VM features as part of the instance configuration.<\/li>\n<li><strong>Why it matters<\/strong>: Enables standardized secure-by-default templates.<\/li>\n<li><strong>Practical benefit<\/strong>: Repeatability across environments and fleets (MIGs, blueprints, IaC).<\/li>\n<li><strong>Limitations\/caveats<\/strong>:<\/li>\n<li>Some changes may require stopping the VM to modify (verify per-field behavior in docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integration with fleet operations (templates, policies, monitoring)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Works with instance templates\/MIGs; integrates with IAM and observability tooling.<\/li>\n<li><strong>Why it matters<\/strong>: Security must be operable at scale.<\/li>\n<li><strong>Practical benefit<\/strong>: You can roll out security posture updates via templates and continuous deployment.<\/li>\n<li><strong>Limitations\/caveats<\/strong>:<\/li>\n<li>Enforcing organization-wide requirements depends on org policy\/IaC controls; confirm the exact enforcement options in current docs.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level service architecture<\/h3>\n\n\n\n<p>At a high level:\n1. You configure a Compute Engine VM with Shielded VM options (Secure Boot, vTPM, Integrity Monitoring).\n2. During VM boot, the platform verifies trusted boot components (Secure Boot) and records boot measurements (vTPM).\n3. Integrity signals are made available for monitoring and operational response (Integrity Monitoring + APIs).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Control flow \/ data flow (conceptual)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane<\/strong>:<\/li>\n<li>VM creation\/update requests go through the <strong>Compute Engine API<\/strong>.<\/li>\n<li>IAM authorizes whether a user\/service account can create\/modify\/view instances and related attributes.<\/li>\n<li><strong>Data plane<\/strong>:<\/li>\n<li>Boot process runs inside the virtualization environment.<\/li>\n<li>vTPM stores measurements\/keys and provides an interface to the guest OS.<\/li>\n<li>Integrity signals are surfaced to Google Cloud\u2019s operational tooling.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud IAM<\/strong>: controls who can create\/modify instances and who can view integrity-related information via APIs.<\/li>\n<li><strong>Cloud Monitoring and alerting<\/strong>: monitor integrity status changes and alert (verify exact metric\/log availability and names).<\/li>\n<li><strong>Cloud Logging<\/strong>: can be used to centralize operational signals (verify what integrity-related events appear as logs in your environment).<\/li>\n<li><strong>Organization Policy<\/strong>: can enforce guardrails across projects\/folders\/org (verify exact constraints that apply to Shielded VM).<\/li>\n<li><strong>Compute Engine instance templates + MIG<\/strong>: apply Shielded VM consistently across fleets.<\/li>\n<li><strong>IAP TCP forwarding<\/strong> (optional but recommended): reduces exposure by removing external IPs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Compute Engine<\/strong> itself (Shielded VM is a feature of Compute Engine VMs).<\/li>\n<li><strong>Cloud APIs<\/strong> (Compute Engine API; optionally Monitoring\/Logging\/IAP depending on your workflow).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM<\/strong> is the core authorization model for:<\/li>\n<li>creating\/updating instances (<code>compute.instances.create<\/code>, <code>compute.instances.update<\/code>, etc.)<\/li>\n<li>reading instance configuration (<code>compute.instances.get<\/code>)<\/li>\n<li>retrieving Shielded VM identity\/measurements (specific permissions; verify roles needed)<\/li>\n<li>Guest OS access (SSH\/RDP) should be controlled using:<\/li>\n<li>OS Login, IAM-based access, and\/or<\/li>\n<li>IAP TCP forwarding<\/li>\n<li>least-privilege firewall rules<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<p>Shielded VM does not change VPC networking by itself. Your VM still uses standard Compute Engine networking:\n&#8211; VPC networks\/subnets\n&#8211; firewall rules\n&#8211; routes\n&#8211; external IPs or Cloud NAT\n&#8211; private Google access, etc.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Decide what \u201caction\u201d means when integrity changes:<\/li>\n<li>alert-only<\/li>\n<li>auto-quarantine (remove from load balancer\/MIG)<\/li>\n<li>auto-recreate from known-good template<\/li>\n<li>Ensure you can link integrity signals to:<\/li>\n<li>instance identity (labels, instance name, template version)<\/li>\n<li>deployment version (image digest, pipeline run ID)<\/li>\n<li>Standardize labeling\/tagging and instance naming to make response fast.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  U[Admin\/CI-CD] --&gt;|Create\/Update VM| CE[Compute Engine API]\n  CE --&gt; VM[Compute Engine VM\\nShielded VM enabled]\n  VM --&gt; SB[Secure Boot]\n  VM --&gt; TPM[vTPM]\n  VM --&gt; IM[Integrity Monitoring]\n  IM --&gt; MON[Cloud Monitoring \/ Alerts]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Org[Google Cloud Organization]\n    subgraph Folder[Folder \/ Landing Zone]\n      subgraph Project[Project: prod-app]\n        VPC[VPC + Subnets] --&gt; MIG[MIG (multi-zone)\\nInstance Template: Shielded VM ON]\n        MIG --&gt; ILB[Load Balancer \/ Backend Service]\n        MIG --&gt; VM1[VM instance (zone A)\\nSecure Boot + vTPM + Integrity Monitoring]\n        MIG --&gt; VM2[VM instance (zone B)\\nSecure Boot + vTPM + Integrity Monitoring]\n\n        VM1 --&gt; Ops[Ops Agent \/ Logs (optional)]\n        VM2 --&gt; Ops\n\n        IM1[Integrity Monitoring signal] --&gt; MON[Cloud Monitoring\\nDashboards + Alerts]\n        IM2[Integrity Monitoring signal] --&gt; MON\n      end\n    end\n  end\n\n  Sec[Security Team] --&gt;|Alert response| MON\n  DevOps[DevOps\/Pipeline] --&gt;|Update template \/ roll out| MIG\n  IAP[IAP TCP forwarding] --&gt;|Admin access (no external IP)| VM1\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Accounts\/projects\/billing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A <strong>Google Cloud project<\/strong> with <strong>billing enabled<\/strong>.<\/li>\n<li>Compute Engine enabled in the project.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>For the hands-on lab, a user typically needs:\n&#8211; Create and manage instances:\n  &#8211; <code>roles\/compute.instanceAdmin.v1<\/code> (common for VM admin)\n&#8211; Set firewall rules (if creating an IAP SSH firewall rule):\n  &#8211; <code>roles\/compute.securityAdmin<\/code> or equivalent least-privilege permissions\n&#8211; If using IAP TCP forwarding:\n  &#8211; <code>roles\/iap.tunnelResourceAccessor<\/code> on the project (or specific instances)<\/p>\n\n\n\n<p>Least privilege varies by organization; confirm with your IAM policies.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Tools<\/h3>\n\n\n\n<p>Choose one:\n&#8211; <strong>Google Cloud Console<\/strong> (browser)\n&#8211; <strong>gcloud CLI<\/strong> (recommended for repeatability): https:\/\/cloud.google.com\/sdk\/docs\/install<\/p>\n\n\n\n<p>Optional tools for verification inside Linux:\n&#8211; <code>tpm2-tools<\/code> package (installed via apt on Debian\/Ubuntu)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Region\/zone availability<\/h3>\n\n\n\n<p>Compute Engine is available in many regions\/zones. Shielded VM feature availability can depend on:\n&#8211; machine type family\n&#8211; image\/OS generation\n&#8211; platform support\nAlways verify support for your chosen OS image and machine type in official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Compute Engine resource quotas (CPUs, instances, IP addresses)<\/li>\n<li>Firewall rule quotas<\/li>\n<li>API rate limits (rare for this lab)<\/li>\n<\/ul>\n\n\n\n<p>See quotas: https:\/\/cloud.google.com\/compute\/quotas<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services \/ APIs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Compute Engine API<\/strong>: <code>compute.googleapis.com<\/code><\/li>\n<li><strong>Cloud Resource Manager API<\/strong> is commonly used in org setups (not required for this lab)<\/li>\n<li>If using IAP for SSH: <strong>IAP<\/strong> configuration may be required in your environment (verify): https:\/\/cloud.google.com\/iap\/docs\/using-tcp-forwarding<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Shielded VM is a <strong>Compute Engine feature<\/strong>. In general, you pay for the underlying resources (VM, disks, networking), and Shielded VM itself is typically not priced as a separate line item. <strong>Verify current pricing behavior in the official pricing pages<\/strong>, because pricing policies can change.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Official pricing sources<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Compute Engine pricing: https:\/\/cloud.google.com\/compute\/all-pricing (or the current Compute Engine pricing page)<\/li>\n<li>Google Cloud Pricing Calculator: https:\/\/cloud.google.com\/products\/calculator<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (what you actually pay for)<\/h3>\n\n\n\n<p>Even when Shielded VM features are enabled, costs usually come from:\n1. <strong>Compute (vCPU and memory)<\/strong>: per-second or per-hour depending on policy (Compute Engine billing granularity is documented by Google).\n2. <strong>Persistent Disk \/ Hyperdisk<\/strong>: size (GB-month), performance tier, snapshots.\n3. <strong>Network<\/strong>:\n   &#8211; egress to the internet\n   &#8211; cross-region traffic\n   &#8211; load balancer data processing where applicable\n4. <strong>External IP<\/strong>: may incur charges when reserved\/unused; policies vary\u2014verify current Compute Engine external IP pricing.\n5. <strong>Operations suite<\/strong> (Monitoring\/Logging):\n   &#8211; additional log ingestion\/storage beyond free allocations\n   &#8211; metrics volume and retention\n6. <strong>IAP<\/strong> itself is typically not billed like bandwidth, but using IAP may shift traffic patterns; verify if any related costs apply in your design.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier considerations<\/h3>\n\n\n\n<p>Compute Engine has a free tier in some regions for certain machine types. This changes over time; verify current details in official docs:\n&#8211; https:\/\/cloud.google.com\/free<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers specific to Shielded VM deployments<\/h3>\n\n\n\n<p>Shielded VM can introduce <strong>indirect<\/strong> costs:\n&#8211; Additional monitoring\/alerting configuration and potential metric\/log usage\n&#8211; Operational overhead responding to integrity alerts (people\/time)\n&#8211; If Secure Boot blocks custom kernels\/drivers, you might need:\n  &#8211; changes in image build pipelines\n  &#8211; additional staging\/testing cycles<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Incident response<\/strong>: integrity alerts are only useful if you have a runbook and staff coverage.<\/li>\n<li><strong>Image pipeline<\/strong>: ensuring compatibility (UEFI, signed boot components) can add build complexity.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<p>Shielded VM itself does not increase network transfer costs, but your <strong>access method<\/strong> can:\n&#8211; Using an external IP for SSH can increase risk and may affect costs if you reserve\/static IPs.\n&#8211; Using <strong>IAP<\/strong> enables \u201cno external IP\u201d patterns and can simplify security posture.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>small machine types<\/strong> for test environments.<\/li>\n<li>Use <strong>no external IP<\/strong> + IAP to reduce exposure (cost-neutral, often a security win).<\/li>\n<li>Use <strong>instance schedules<\/strong> for non-production to stop VMs when not needed.<\/li>\n<li>Keep logs\/metrics purposeful:<\/li>\n<li>alert on high-signal conditions<\/li>\n<li>avoid excessive debug logging in production<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (conceptual)<\/h3>\n\n\n\n<p>A minimal lab VM typically includes:\n&#8211; 1 small general-purpose VM (for example, E2 family)\n&#8211; a small boot disk (standard persistent disk)\n&#8211; minimal egress\n&#8211; limited log volume<\/p>\n\n\n\n<p>Use the pricing calculator for your region and exact specs:\n&#8211; https:\/\/cloud.google.com\/products\/calculator<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>For production fleets (MIG across multiple zones), expect cost drivers from:\n&#8211; total vCPU\/RAM across the fleet\n&#8211; load balancers and egress traffic\n&#8211; larger\/faster disks\n&#8211; observability volume and retention\n&#8211; higher availability (multi-zone) increasing baseline instance count<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Create a <strong>Shielded VM-enabled Compute Engine instance<\/strong> with:\n&#8211; Secure Boot enabled\n&#8211; vTPM enabled\n&#8211; Integrity Monitoring enabled<\/p>\n\n\n\n<p>Then:\n&#8211; verify the Shielded VM configuration\n&#8211; validate that the guest OS can see a TPM device (Linux)\n&#8211; retrieve Shielded VM identity\/measurements using the Compute Engine API\n&#8211; clean up all resources safely<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Configure gcloud and enable required APIs.\n2. Create a firewall rule for SSH via IAP (so the VM has no external IP).\n3. Create a Debian VM with Shielded VM enabled.\n4. SSH to the VM via IAP and verify Secure Boot\/UEFI + TPM presence.\n5. Call the Compute Engine API to retrieve Shielded VM identity\/measurements.\n6. Delete the VM and firewall rule.<\/p>\n\n\n\n<p>This lab is designed to be low-cost, but <strong>any VM usage can incur charges<\/strong>. Use the pricing calculator and delete resources at the end.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Set up your environment (project, region\/zone, APIs)<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">1.1 Authenticate and select a project<\/h4>\n\n\n\n<pre><code class=\"language-bash\">gcloud auth login\ngcloud config set project YOUR_PROJECT_ID\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">1.2 Choose a zone<\/h4>\n\n\n\n<p>Pick a zone close to you. Example:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud config set compute\/zone us-central1-a\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">1.3 Enable the Compute Engine API<\/h4>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable compute.googleapis.com\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: Compute Engine API is enabled.<\/p>\n\n\n\n<p><strong>Verification<\/strong>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services list --enabled --filter=\"name:compute.googleapis.com\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create an IAP SSH firewall rule (recommended)<\/h3>\n\n\n\n<p>This lab uses <strong>no external IP<\/strong> and connects using <strong>IAP TCP forwarding<\/strong>. That means you must allow SSH <strong>from IAP\u2019s IP range<\/strong> to the VM.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">2.1 Create a firewall rule to allow SSH from IAP to instances with a network tag<\/h4>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute firewall-rules create allow-ssh-from-iap \\\n  --direction=INGRESS \\\n  --priority=1000 \\\n  --network=default \\\n  --action=ALLOW \\\n  --rules=tcp:22 \\\n  --source-ranges=35.235.240.0\/20 \\\n  --target-tags=iap-ssh\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: A firewall rule exists allowing inbound TCP 22 only from IAP to tagged VMs.<\/p>\n\n\n\n<p><strong>Verification<\/strong>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute firewall-rules describe allow-ssh-from-iap\n<\/code><\/pre>\n\n\n\n<blockquote>\n<p>If your organization doesn\u2019t allow using the <code>default<\/code> network, create\/select an approved VPC\/subnet and apply the same pattern.<\/p>\n<\/blockquote>\n\n\n\n<h4 class=\"wp-block-heading\">2.2 Ensure you have IAP permissions<\/h4>\n\n\n\n<p>You typically need:\n&#8211; <code>roles\/iap.tunnelResourceAccessor<\/code><\/p>\n\n\n\n<p>If you can\u2019t connect later, ask your admin to grant it (least privilege) or test with a project you control.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create a Shielded VM instance (Secure Boot + vTPM + Integrity Monitoring)<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">3.1 Create the VM<\/h4>\n\n\n\n<p>This example uses Debian. You can choose other supported images, but Secure Boot compatibility can vary\u2014verify in the Shielded VM docs if you use a different OS.<\/p>\n\n\n\n<pre><code class=\"language-bash\">INSTANCE_NAME=shielded-lab-vm\n\ngcloud compute instances create \"$INSTANCE_NAME\" \\\n  --machine-type=e2-small \\\n  --image-family=debian-12 \\\n  --image-project=debian-cloud \\\n  --boot-disk-size=20GB \\\n  --no-address \\\n  --tags=iap-ssh \\\n  --shielded-secure-boot \\\n  --shielded-vtpm \\\n  --shielded-integrity-monitoring\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: A VM is created with Shielded VM features enabled and <strong>no external IP<\/strong>.<\/p>\n\n\n\n<p><strong>Verification (configuration)<\/strong>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute instances describe \"$INSTANCE_NAME\" \\\n  --format=\"yaml(name,zone,networkInterfaces[].networkIP,shieldedInstanceConfig)\"\n<\/code><\/pre>\n\n\n\n<p>You should see <code>shieldedInstanceConfig<\/code> fields indicating Secure Boot, vTPM, and integrity monitoring are enabled.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">3.2 Verify in the Cloud Console (optional but useful)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Go to <strong>Compute Engine &gt; VM instances<\/strong><\/li>\n<li>Click the instance<\/li>\n<li>Look for <strong>Security \/ Shielded VM<\/strong> settings and integrity status<\/li>\n<\/ul>\n\n\n\n<p>The exact console UI labels can change; use the Shielded VM docs if needed.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Connect to the VM via IAP and verify TPM + UEFI\/Secure Boot indicators<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">4.1 SSH using IAP TCP forwarding<\/h4>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute ssh \"$INSTANCE_NAME\" --tunnel-through-iap\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: You get a shell on the VM without using an external IP.<\/p>\n\n\n\n<p>If prompted to create SSH keys, accept (gcloud manages user keys unless your org uses OS Login).<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">4.2 Verify UEFI presence (common indicator when Secure Boot is in play)<\/h4>\n\n\n\n<p>Inside the VM:<\/p>\n\n\n\n<pre><code class=\"language-bash\">test -d \/sys\/firmware\/efi &amp;&amp; echo \"UEFI detected\" || echo \"UEFI not detected\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: Typically <code>UEFI detected<\/code> for Secure Boot-capable instances.<br\/>\nIf you see <code>UEFI not detected<\/code>, verify image compatibility and Shielded VM requirements in official docs.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">4.3 Verify TPM device presence<\/h4>\n\n\n\n<pre><code class=\"language-bash\">ls -l \/dev\/tpm* || true\ndmesg | grep -i tpm || true\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: You should generally see a TPM device node (often <code>\/dev\/tpm0<\/code>) and kernel messages indicating a TPM device.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">4.4 (Optional) Read TPM PCRs with tpm2-tools<\/h4>\n\n\n\n<p>Install tools:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo apt-get update\nsudo apt-get install -y tpm2-tools\n<\/code><\/pre>\n\n\n\n<p>Read PCRs:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo tpm2_pcrread sha256:0,1,2,3,4,5,6,7\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: You see PCR values. These are part of measured boot signals.<\/p>\n\n\n\n<p>Exit SSH:<\/p>\n\n\n\n<pre><code class=\"language-bash\">exit\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Retrieve Shielded VM identity\/measurements via Compute Engine API<\/h3>\n\n\n\n<p>Compute Engine provides an API endpoint for Shielded VM identity\/measurements.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">5.1 Get an access token<\/h4>\n\n\n\n<pre><code class=\"language-bash\">ACCESS_TOKEN=\"$(gcloud auth print-access-token)\"\necho \"${#ACCESS_TOKEN}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: The token length prints as a non-zero number.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">5.2 Call the <code>getShieldedInstanceIdentity<\/code> endpoint<\/h4>\n\n\n\n<pre><code class=\"language-bash\">PROJECT_ID=\"$(gcloud config get-value project)\"\nZONE=\"$(gcloud config get-value compute\/zone)\"\n\ncurl -sS -H \"Authorization: Bearer ${ACCESS_TOKEN}\" \\\n  \"https:\/\/compute.googleapis.com\/compute\/v1\/projects\/${PROJECT_ID}\/zones\/${ZONE}\/instances\/${INSTANCE_NAME}\/getShieldedInstanceIdentity\" \\\n  | head -n 50\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: JSON output (identity and measurement-related data). The exact JSON fields can evolve; rely on the official API reference for interpretation:\n&#8211; Compute Engine API reference: https:\/\/cloud.google.com\/compute\/docs\/reference\/rest\/v1\/instances\/getShieldedInstanceIdentity (verify URL path in current docs if it changes)<\/p>\n\n\n\n<p><strong>Common permission issue<\/strong>: If you get <code>403 PERMISSION_DENIED<\/code>, your account may be missing permissions to call that method. Ensure you have appropriate Compute Engine read permissions.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Instance created<\/strong>:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute instances list --filter=\"name=${INSTANCE_NAME}\"\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"2\">\n<li><strong>Shielded VM configuration enabled<\/strong>:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute instances describe \"${INSTANCE_NAME}\" \\\n  --format=\"yaml(shieldedInstanceConfig)\"\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"3\">\n<li><strong>SSH access via IAP works<\/strong>:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute ssh \"${INSTANCE_NAME}\" --tunnel-through-iap --command=\"uname -a\"\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"4\">\n<li><strong>TPM device present<\/strong> (Linux):<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute ssh \"${INSTANCE_NAME}\" --tunnel-through-iap --command=\"ls -l \/dev\/tpm* || true\"\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"5\">\n<li><strong>API returns Shielded identity\/measurements<\/strong>:\nThe curl call returns JSON (Step 5).<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: <code>gcloud compute ssh ... --tunnel-through-iap<\/code> fails<\/h4>\n\n\n\n<p>Common causes and fixes:\n&#8211; Missing role: grant <code>roles\/iap.tunnelResourceAccessor<\/code>\n&#8211; Firewall rule missing or wrong network\/tag:\n  &#8211; ensure the VM has the <code>iap-ssh<\/code> tag\n  &#8211; ensure firewall rule targets <code>iap-ssh<\/code>\n  &#8211; ensure source range is <code>35.235.240.0\/20<\/code>\n&#8211; Organization policy blocks IAP\/SSH patterns:\n  &#8211; use approved access methods in your org<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: VM fails to boot after enabling Secure Boot<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>This often indicates the boot chain is not compatible with Secure Boot (custom kernel\/driver\/image issue).<\/li>\n<li>Fix: stop the VM and disable Secure Boot (how you do this depends on current Compute Engine capabilities and UI\/API behavior\u2014verify in official docs). In production, prefer rebuilding the image to be compatible rather than weakening the baseline.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: No <code>\/dev\/tpm0<\/code> inside the VM<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Confirm vTPM is enabled in the instance configuration.<\/li>\n<li>Confirm the OS supports TPM devices.<\/li>\n<li>Try a different supported image and re-test.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: <code>403<\/code> on getShieldedInstanceIdentity<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Ensure you have compute permissions to read that data. Try <code>roles\/compute.viewer<\/code> at minimum, then add more only as necessary.<\/li>\n<li>Verify the API endpoint and method name in the current REST reference.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>Delete the VM:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute instances delete \"${INSTANCE_NAME}\" --quiet\n<\/code><\/pre>\n\n\n\n<p>Delete the firewall rule:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute firewall-rules delete allow-ssh-from-iap --quiet\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: No running VM instances from this lab and no extra firewall rule.<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute instances list --filter=\"name=${INSTANCE_NAME}\"\ngcloud compute firewall-rules list --filter=\"name=allow-ssh-from-iap\"\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Standardize Shielded VM in instance templates<\/strong> for MIG-based workloads.<\/li>\n<li>Prefer <strong>immutable infrastructure<\/strong>:<\/li>\n<li>treat VMs as replaceable<\/li>\n<li>roll forward by rebuilding images and replacing instances<\/li>\n<li>Use <strong>multi-zone<\/strong> designs for production services; Shielded VM is complementary to availability patterns.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Apply <strong>least privilege<\/strong>:<\/li>\n<li>separate roles for VM creation, network security, and monitoring access<\/li>\n<li>Restrict who can:<\/li>\n<li>disable Secure Boot<\/li>\n<li>create instances from unapproved images<\/li>\n<li>Use <strong>service accounts<\/strong> per workload and minimal OAuth scopes (where applicable; Compute Engine now emphasizes IAM over legacy scopes\u2014verify current guidance).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>For dev\/test, use:<\/li>\n<li>smaller machine types<\/li>\n<li>schedules\/automation to stop VMs<\/li>\n<li>Keep integrity monitoring signals actionable; avoid collecting data you won\u2019t operationalize.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Test Secure Boot compatibility and boot times in staging.<\/li>\n<li>Validate kernel\/module requirements early (especially for appliances or workloads with custom drivers).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Treat integrity alerts as potential \u201cnode compromise\u201d signals:<\/li>\n<li>remove node from service<\/li>\n<li>recreate from a known-good template\/image<\/li>\n<li>Keep <strong>golden images<\/strong> versioned and reproducible (Packer + artifact registry patterns).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create runbooks for:<\/li>\n<li>\u201cIntegrity status changed\u201d events<\/li>\n<li>remediation steps (cordon\/drain, replace, forensics)<\/li>\n<li>Use consistent <strong>labels<\/strong>:<\/li>\n<li><code>env=prod\/dev<\/code><\/li>\n<li><code>app=...<\/code><\/li>\n<li><code>image_version=...<\/code><\/li>\n<li><code>owner_team=...<\/code><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use consistent naming: <code>app-env-role-zone-seq<\/code><\/li>\n<li>Enforce labels through policy or CI checks where possible.<\/li>\n<li>Track instance template versions and rollout history.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Shielded VM is configured and queried via <strong>Compute Engine APIs<\/strong>, governed by <strong>Cloud IAM<\/strong>.<\/li>\n<li>Control access to:<\/li>\n<li>instance creation\/modification<\/li>\n<li>instance metadata and APIs that expose identity\/measurements<\/li>\n<li>Strongly consider:<\/li>\n<li><strong>OS Login<\/strong> for SSH with IAM-based access management<\/li>\n<li><strong>IAP TCP forwarding<\/strong> to remove external IP exposure<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Data at rest<\/strong>: Compute Engine disks are encrypted by default; you can also use <strong>CMEK<\/strong> for additional control.<\/li>\n<li><strong>Data in transit<\/strong>: standard TLS practices apply.<\/li>\n<li><strong>Data in use (memory)<\/strong>: Shielded VM does not encrypt RAM; for that, evaluate <strong>Confidential VM<\/strong> (separate feature with different tradeoffs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Shielded VM does not replace network controls:<\/li>\n<li>use least-privilege firewall rules<\/li>\n<li>avoid public SSH\/RDP when possible<\/li>\n<li>prefer private subnets + NAT + IAP<\/li>\n<li>Segment workloads:<\/li>\n<li>separate admin, app, and data tiers with firewall rules and subnets<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Store secrets in <strong>Secret Manager<\/strong> rather than instance metadata or disk.<\/li>\n<li>Use short-lived credentials and workload identity patterns where applicable (verify best fit for your runtime).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable and centralize:<\/li>\n<li><strong>Cloud Audit Logs<\/strong> for Compute Engine API activity<\/li>\n<li>logs for IAM policy changes<\/li>\n<li>Treat changes to Shielded VM settings (like disabling Secure Boot) as high-signal events to review.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<p>Shielded VM can support compliance objectives, but it is not a standalone compliance solution. Combine it with:\n&#8211; IAM governance\n&#8211; vulnerability management and patching\n&#8211; logging\/monitoring controls\n&#8211; incident response procedures\n&#8211; image supply chain controls<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enabling Shielded VM but leaving <strong>SSH open to the internet<\/strong> (<code>0.0.0.0\/0<\/code>) with weak access controls.<\/li>\n<li>Treating integrity monitoring as \u201cmalware detection.\u201d It\u2019s primarily about <strong>boot integrity<\/strong>, not full runtime security.<\/li>\n<li>Allowing too many people to modify instance templates or disable secure settings without review.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Make Shielded VM your <strong>default<\/strong> for new VMs unless you have a tested exception.<\/li>\n<li>Use <strong>IAP + OS Login<\/strong> for admin access.<\/li>\n<li>Use <strong>MIGs<\/strong> and replace instances on integrity anomalies rather than trying to \u201crepair\u201d in place.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Because Shielded VM operates at a low level, compatibility details matter. Key gotchas include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Secure Boot compatibility<\/strong>: custom kernels, unsigned boot components, and some specialized drivers can break boot. Validate in staging.<\/li>\n<li><strong>OS\/image support differences<\/strong>: not every OS image or configuration supports every Shielded VM feature the same way. Verify supported images in official docs.<\/li>\n<li><strong>Integrity Monitoring scope<\/strong>: it focuses on boot integrity; it does not guarantee the OS is uncompromised after boot.<\/li>\n<li><strong>Operational readiness<\/strong>: enabling integrity monitoring without a response plan can create alert fatigue or ignored signals.<\/li>\n<li><strong>Change management<\/strong>: changing Shielded settings might require instance stop\/start or recreation depending on what\u2019s being changed\u2014verify in current docs for each setting.<\/li>\n<li><strong>Fleet rollouts<\/strong>: in MIGs, a template change affects new instances; existing instances may require rolling replacement.<\/li>\n<li><strong>Observability costs<\/strong>: if integrity signals generate logs\/metrics at scale, costs can rise (especially across large fleets).<\/li>\n<li><strong>Multi-layer security confusion<\/strong>: Shielded VM is not the same as:<\/li>\n<li>network DDoS protection<\/li>\n<li>WAF<\/li>\n<li>runtime sandboxing<\/li>\n<li>memory encryption (Confidential VM)<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Shielded VM is best understood as <strong>boot integrity and measured boot protections<\/strong> for Compute Engine VMs. Alternatives often focus on different threat models.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Google Cloud Shielded VM (Compute Engine)<\/strong><\/td>\n<td>Boot integrity hardening for VMs<\/td>\n<td>Secure Boot + vTPM + integrity signals; integrates with Compute Engine<\/td>\n<td>Secure Boot may break custom kernel\/driver workflows; not runtime malware detection<\/td>\n<td>Default baseline for VM fleets that can support Secure Boot<\/td>\n<\/tr>\n<tr>\n<td><strong>Standard Compute Engine VM (no Shielded features)<\/strong><\/td>\n<td>Maximum compatibility<\/td>\n<td>Fewer boot constraints<\/td>\n<td>Less protection against bootkits\/rootkits<\/td>\n<td>Only when Shielded VM is incompatible and risk is accepted\/mitigated elsewhere<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Cloud Confidential VM<\/strong><\/td>\n<td>Protecting data in use (memory encryption)<\/td>\n<td>Stronger protection against memory inspection in certain threat models<\/td>\n<td>Different goal than Shielded VM; may have compatibility\/perf tradeoffs<\/td>\n<td>Use when memory confidentiality is required; can be complementary (verify combinations in docs)<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Cloud OS Login + IAP (access controls)<\/strong><\/td>\n<td>Reducing admin access risk<\/td>\n<td>Strong IAM-governed access; reduces exposure<\/td>\n<td>Does not protect boot chain<\/td>\n<td>Use alongside Shielded VM; not a replacement<\/td>\n<\/tr>\n<tr>\n<td><strong>Microsoft Azure Trusted Launch<\/strong><\/td>\n<td>Azure VM boot integrity features<\/td>\n<td>Similar concepts: Secure Boot + vTPM + monitoring<\/td>\n<td>Different cloud ecosystem; migration overhead<\/td>\n<td>Choose when on Azure and you need analogous protections<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS UEFI Secure Boot + NitroTPM (where supported)<\/strong><\/td>\n<td>AWS VM boot integrity primitives<\/td>\n<td>TPM-like and secure boot capabilities on supported instances<\/td>\n<td>Feature availability varies by instance type\/OS<\/td>\n<td>Choose when on AWS and you need similar boot integrity building blocks<\/td>\n<\/tr>\n<tr>\n<td><strong>On-prem Secure Boot + Hardware TPM<\/strong><\/td>\n<td>Physical control and hardware-root trust<\/td>\n<td>Hardware attestation options<\/td>\n<td>Higher ops overhead; scaling and automation complexity<\/td>\n<td>Choose when regulatory\/latency constraints require on-prem and you can manage hardware<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<p>Notes:\n&#8211; Cross-cloud feature parity is not exact; verify current offerings and supported combinations in each cloud\u2019s official docs.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: regulated payment service on Compute Engine<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A payments platform runs VM-based services that process sensitive transactions. Security needs include platform integrity signals, strong access controls, and standardized hardening.<\/li>\n<li><strong>Proposed architecture<\/strong>:<\/li>\n<li>Multi-zone MIG for stateless API tier<\/li>\n<li>Shielded VM enabled in instance templates (Secure Boot + vTPM + Integrity Monitoring)<\/li>\n<li>OS Login + IAP for admin access; no external IPs<\/li>\n<li>Centralized Cloud Audit Logs; Monitoring alerts for integrity anomalies<\/li>\n<li>Immutable image pipeline with signed\/validated boot components (process depends on OS and enterprise tooling)<\/li>\n<li><strong>Why Shielded VM was chosen<\/strong>:<\/li>\n<li>Directly addresses boot-chain tampering threats<\/li>\n<li>Operable at scale through templates\/MIGs<\/li>\n<li>Provides measurable signals for monitoring and audit narratives<\/li>\n<li><strong>Expected outcomes<\/strong>:<\/li>\n<li>Reduced likelihood of stealth persistence via bootkits<\/li>\n<li>Faster detection\/triage if boot integrity changes<\/li>\n<li>More consistent baseline across teams and environments<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: SaaS API backend with small ops team<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A small SaaS team runs a few VM services (API, background workers). They want better baseline security without hiring a large security staff.<\/li>\n<li><strong>Proposed architecture<\/strong>:<\/li>\n<li>1\u20132 MIGs (API and worker)<\/li>\n<li>Shielded VM enabled by default<\/li>\n<li>No external IPs; admin access via IAP<\/li>\n<li>Basic alerting on integrity status changes; automated instance recreation on suspicious signals<\/li>\n<li><strong>Why Shielded VM was chosen<\/strong>:<\/li>\n<li>Low operational complexity compared to custom secure boot implementations<\/li>\n<li>Helps cover a serious class of attacks with minimal configuration changes<\/li>\n<li><strong>Expected outcomes<\/strong>:<\/li>\n<li>Stronger security posture for customer trust and sales questionnaires<\/li>\n<li>Clearer operational response patterns (\u201creplace instance from template\u201d)<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Is Shielded VM a separate Google Cloud product?<\/strong><br\/>\n   No. Shielded VM is a set of security features for <strong>Compute Engine<\/strong> VM instances.<\/p>\n<\/li>\n<li>\n<p><strong>Does Shielded VM protect against all malware?<\/strong><br\/>\n   No. It primarily addresses <strong>boot integrity<\/strong> threats (bootkits\/rootkits) and provides integrity signals. You still need OS hardening, patching, and endpoint detection strategies.<\/p>\n<\/li>\n<li>\n<p><strong>What\u2019s the difference between Shielded VM and Confidential VM?<\/strong><br\/>\n   Shielded VM focuses on <strong>secure\/measured boot and integrity<\/strong>. Confidential VM focuses on <strong>encrypting data in memory (data in use)<\/strong>. They solve different problems.<\/p>\n<\/li>\n<li>\n<p><strong>Does enabling Secure Boot guarantee my VM can\u2019t be compromised?<\/strong><br\/>\n   No. It raises the bar against boot-chain tampering but does not eliminate all attack paths (application vulnerabilities, credential theft, runtime exploits, etc.).<\/p>\n<\/li>\n<li>\n<p><strong>Will Secure Boot break my workload?<\/strong><br\/>\n   It can if you require unsigned boot components, custom kernels, or incompatible drivers. Test in staging with your exact image and startup scripts.<\/p>\n<\/li>\n<li>\n<p><strong>Can I enable Shielded VM on existing instances?<\/strong><br\/>\n   Some settings may be changeable, but behavior varies. In practice, many teams enable Shielded VM via <strong>recreating instances<\/strong> from updated templates. Verify current capabilities in official docs.<\/p>\n<\/li>\n<li>\n<p><strong>Do I pay extra for Shielded VM?<\/strong><br\/>\n   Typically you pay for the underlying Compute Engine resources; Shielded VM itself is generally not billed separately. <strong>Verify current pricing<\/strong> on official pricing pages.<\/p>\n<\/li>\n<li>\n<p><strong>How do I monitor integrity changes at scale?<\/strong><br\/>\n   Use fleet patterns: standardized labels, Monitoring dashboards\/alerts, and automated remediation (remove from service and recreate). Verify where integrity signals surface in your current Google Cloud setup.<\/p>\n<\/li>\n<li>\n<p><strong>What IAM roles are needed to retrieve Shielded VM identity\/measurements?<\/strong><br\/>\n   It depends on the API method and your org\u2019s policies. Start with least privilege and consult the Compute Engine IAM permissions for the specific method (for example, <code>instances.getShieldedInstanceIdentity<\/code>).<\/p>\n<\/li>\n<li>\n<p><strong>Can Shielded VM help with supply-chain security for VM images?<\/strong><br\/>\n   Yes as part of a broader approach: Secure Boot can prevent unauthorized boot components from running, and measured boot signals can help validate expected boot states.<\/p>\n<\/li>\n<li>\n<p><strong>Does Shielded VM replace OS patching?<\/strong><br\/>\n   No. Patch management remains essential.<\/p>\n<\/li>\n<li>\n<p><strong>Does Shielded VM change how networking works?<\/strong><br\/>\n   No. VPC, firewall rules, and IP addressing behave normally.<\/p>\n<\/li>\n<li>\n<p><strong>Can I use Shielded VM with MIG rolling updates?<\/strong><br\/>\n   Yes. Shielded VM settings belong in the <strong>instance template<\/strong>. Rolling updates then apply the template to new instances.<\/p>\n<\/li>\n<li>\n<p><strong>How do I validate vTPM is present in Linux?<\/strong><br\/>\n   Common checks include <code>\/dev\/tpm0<\/code>, <code>dmesg | grep -i tpm<\/code>, and using <code>tpm2-tools<\/code> to read PCRs.<\/p>\n<\/li>\n<li>\n<p><strong>What should I do if integrity monitoring reports an issue?<\/strong><br\/>\n   Treat it as a potential compromise or unauthorized change:\n   &#8211; remove the instance from service\n   &#8211; snapshot disks only if needed for forensics (be mindful of handling sensitive data)\n   &#8211; recreate from a known-good template\/image\n   &#8211; investigate deployment changes and IAM activity<\/p>\n<\/li>\n<li>\n<p><strong>Is Shielded VM enough for high-security environments?<\/strong><br\/>\n   It\u2019s a strong baseline control, but high-security environments typically require layered controls: IAM, network segmentation, logging, vulnerability management, secrets management, and incident response processes.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Shielded VM<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Shielded VM documentation (Compute Engine) \u2014 https:\/\/cloud.google.com\/compute\/shielded-vm\/docs<\/td>\n<td>Primary source for capabilities, requirements, and configuration details<\/td>\n<\/tr>\n<tr>\n<td>Official API reference<\/td>\n<td>Compute Engine Instances REST reference \u2014 https:\/\/cloud.google.com\/compute\/docs\/reference\/rest\/v1\/instances<\/td>\n<td>Authoritative reference for methods like <code>getShieldedInstanceIdentity<\/code><\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Compute Engine pricing \u2014 https:\/\/cloud.google.com\/compute\/all-pricing<\/td>\n<td>Understand what you\u2019re billed for (VM, disks, network)<\/td>\n<\/tr>\n<tr>\n<td>Official cost tool<\/td>\n<td>Pricing Calculator \u2014 https:\/\/cloud.google.com\/products\/calculator<\/td>\n<td>Estimate cost by region and configuration<\/td>\n<\/tr>\n<tr>\n<td>Official security guidance<\/td>\n<td>Google Cloud security documentation \u2014 https:\/\/cloud.google.com\/security<\/td>\n<td>Broader best practices and security architecture context<\/td>\n<\/tr>\n<tr>\n<td>Official quotas<\/td>\n<td>Compute Engine quotas \u2014 https:\/\/cloud.google.com\/compute\/quotas<\/td>\n<td>Plan limits for instances, CPUs, firewall rules<\/td>\n<\/tr>\n<tr>\n<td>Official access pattern<\/td>\n<td>IAP TCP forwarding \u2014 https:\/\/cloud.google.com\/iap\/docs\/using-tcp-forwarding<\/td>\n<td>Recommended admin access pattern for VMs without external IPs<\/td>\n<\/tr>\n<tr>\n<td>Official free tier<\/td>\n<td>Google Cloud Free Program \u2014 https:\/\/cloud.google.com\/free<\/td>\n<td>Validate if your lab can run under free tier constraints<\/td>\n<\/tr>\n<tr>\n<td>Architecture guidance<\/td>\n<td>Google Cloud Architecture Center \u2014 https:\/\/cloud.google.com\/architecture<\/td>\n<td>Reference architectures and design patterns that complement Shielded VM<\/td>\n<\/tr>\n<tr>\n<td>Community learning<\/td>\n<td>Google Cloud Skills Boost \u2014 https:\/\/www.cloudskillsboost.google<\/td>\n<td>Hands-on labs (availability of Shielded VM-specific labs varies; search the catalog)<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<p>Below are training providers (listed exactly as requested). Details like course depth, delivery, and schedules can change\u2014check each website.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>DevOpsSchool.com<\/strong><br\/>\n   &#8211; Suitable audience: DevOps engineers, SREs, cloud engineers, platform teams<br\/>\n   &#8211; Likely learning focus: Google Cloud operations, DevOps practices, CI\/CD, infrastructure automation, cloud security basics<br\/>\n   &#8211; Mode: check website<br\/>\n   &#8211; Website: https:\/\/www.devopsschool.com\/<\/p>\n<\/li>\n<li>\n<p><strong>ScmGalaxy.com<\/strong><br\/>\n   &#8211; Suitable audience: Developers, DevOps beginners to intermediate practitioners<br\/>\n   &#8211; Likely learning focus: SCM, DevOps tooling, CI\/CD concepts, cloud fundamentals<br\/>\n   &#8211; Mode: check website<br\/>\n   &#8211; Website: https:\/\/www.scmgalaxy.com\/<\/p>\n<\/li>\n<li>\n<p><strong>CLoudOpsNow.in<\/strong><br\/>\n   &#8211; Suitable audience: Cloud operations engineers, SREs, infrastructure teams<br\/>\n   &#8211; Likely learning focus: Cloud operations, monitoring, reliability patterns, incident response practices<br\/>\n   &#8211; Mode: check website<br\/>\n   &#8211; Website: https:\/\/www.cloudopsnow.in\/<\/p>\n<\/li>\n<li>\n<p><strong>SreSchool.com<\/strong><br\/>\n   &#8211; Suitable audience: SREs, operations teams, platform engineers<br\/>\n   &#8211; Likely learning focus: SRE principles, monitoring\/alerting, error budgets, reliability engineering<br\/>\n   &#8211; Mode: check website<br\/>\n   &#8211; Website: https:\/\/www.sreschool.com\/<\/p>\n<\/li>\n<li>\n<p><strong>AiOpsSchool.com<\/strong><br\/>\n   &#8211; Suitable audience: Ops teams, SREs, engineers exploring AIOps practices<br\/>\n   &#8211; Likely learning focus: Observability, automation, event correlation, operational analytics concepts<br\/>\n   &#8211; Mode: check website<br\/>\n   &#8211; Website: https:\/\/www.aiopsschool.com\/<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<p>These are trainer-related sites (listed exactly as requested). Treat them as training resources\/platforms and verify offerings directly.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>RajeshKumar.xyz<\/strong><br\/>\n   &#8211; Likely specialization: DevOps\/cloud training and guidance (verify current focus on website)<br\/>\n   &#8211; Suitable audience: Beginners to working professionals seeking practical DevOps\/cloud skills<br\/>\n   &#8211; Website: https:\/\/rajeshkumar.xyz\/<\/p>\n<\/li>\n<li>\n<p><strong>devopstrainer.in<\/strong><br\/>\n   &#8211; Likely specialization: DevOps tools, CI\/CD, cloud fundamentals (verify catalog)<br\/>\n   &#8211; Suitable audience: DevOps learners and engineers seeking hands-on coaching<br\/>\n   &#8211; Website: https:\/\/www.devopstrainer.in\/<\/p>\n<\/li>\n<li>\n<p><strong>devopsfreelancer.com<\/strong><br\/>\n   &#8211; Likely specialization: DevOps consulting\/training resources (verify current services)<br\/>\n   &#8211; Suitable audience: Teams or individuals looking for project-based help or mentoring<br\/>\n   &#8211; Website: https:\/\/www.devopsfreelancer.com\/<\/p>\n<\/li>\n<li>\n<p><strong>devopssupport.in<\/strong><br\/>\n   &#8211; Likely specialization: DevOps support and training (verify current offerings)<br\/>\n   &#8211; Suitable audience: Engineers needing operational support or guided learning<br\/>\n   &#8211; Website: https:\/\/www.devopssupport.in\/<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<p>These consulting companies are listed exactly as requested. Descriptions are kept neutral; verify services and references directly.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>cotocus.com<\/strong><br\/>\n   &#8211; Likely service area: Cloud\/DevOps consulting and implementation (verify service catalog)<br\/>\n   &#8211; Where they may help: cloud migrations, CI\/CD setup, operational readiness, security hardening<br\/>\n   &#8211; Consulting use case examples:  <\/p>\n<ul>\n<li>Implementing hardened VM baselines (Shielded VM + IAM + IAP patterns)  <\/li>\n<li>Building image pipelines and deployment automation  <\/li>\n<li>Website: https:\/\/cotocus.com\/<\/li>\n<\/ul>\n<\/li>\n<li>\n<p><strong>DevOpsSchool.com<\/strong><br\/>\n   &#8211; Likely service area: DevOps and cloud consulting\/training services (verify consulting offerings)<br\/>\n   &#8211; Where they may help: platform engineering enablement, CI\/CD, cloud governance, SRE practices<br\/>\n   &#8211; Consulting use case examples:  <\/p>\n<ul>\n<li>Rolling out Shielded VM across instance templates and MIGs  <\/li>\n<li>Designing monitoring\/alerting runbooks for integrity signals  <\/li>\n<li>Website: https:\/\/www.devopsschool.com\/<\/li>\n<\/ul>\n<\/li>\n<li>\n<p><strong>DEVOPSCONSULTING.IN<\/strong><br\/>\n   &#8211; Likely service area: DevOps consulting services (verify current portfolio)<br\/>\n   &#8211; Where they may help: DevOps transformations, automation, cloud operations, security posture improvements<br\/>\n   &#8211; Consulting use case examples:  <\/p>\n<ul>\n<li>Establishing secure VM access patterns (OS Login\/IAP) and hardened compute templates  <\/li>\n<li>Creating governance checks in CI to prevent insecure VM configurations  <\/li>\n<li>Website: https:\/\/www.devopsconsulting.in\/<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Shielded VM<\/h3>\n\n\n\n<p>To use Shielded VM effectively, you should understand:\n&#8211; Compute Engine basics: instances, disks, images, instance templates, MIGs\n&#8211; VPC networking: subnets, firewall rules, routes, NAT\n&#8211; IAM fundamentals: roles, service accounts, least privilege\n&#8211; Linux boot basics (helpful): bootloader, kernel, modules\n&#8211; Basic security operations: logging, monitoring, alerting<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Shielded VM<\/h3>\n\n\n\n<p>To build a robust compute security posture:\n&#8211; <strong>Confidential VM<\/strong> (data-in-use protection) if needed\n&#8211; OS hardening benchmarks (CIS-style guidance) and patch automation\n&#8211; Golden image pipelines (Packer) and artifact provenance\n&#8211; Organization policy guardrails and policy-as-code\n&#8211; Incident response for cloud workloads (forensics readiness, isolation, rebuild strategies)\n&#8211; Zero Trust access patterns (IAP, BeyondCorp Enterprise if applicable)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud\/solutions architect<\/li>\n<li>Platform engineer<\/li>\n<li>DevOps engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Cloud security engineer<\/li>\n<li>Security operations \/ detection engineer (integrating integrity signals into triage)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (Google Cloud)<\/h3>\n\n\n\n<p>Shielded VM is a feature within Compute Engine\/security architecture. Relevant Google Cloud certifications (verify current names\/availability):\n&#8211; Associate Cloud Engineer\n&#8211; Professional Cloud Architect\n&#8211; Professional Cloud Security Engineer\n&#8211; Professional DevOps Engineer<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a MIG-based web service where every instance is Shielded VM-enabled.<\/li>\n<li>Add a CI check that validates instance templates have Shielded VM enabled (using <code>gcloud<\/code> + policy checks).<\/li>\n<li>Create a runbook and automation to recreate instances if integrity status changes (start with alert-only).<\/li>\n<li>Build a simple attestation verifier prototype using <code>getShieldedInstanceIdentity<\/code> (carefully handle baselines and false positives).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Compute Engine<\/strong>: Google Cloud\u2019s IaaS service for running virtual machines.<\/li>\n<li><strong>Shielded VM<\/strong>: Compute Engine security features to protect against boot-level compromise (Secure Boot, vTPM, Integrity Monitoring).<\/li>\n<li><strong>Secure Boot<\/strong>: A mechanism that verifies boot components are signed\/trusted before executing.<\/li>\n<li><strong>UEFI<\/strong>: Modern firmware interface used by Secure Boot-capable systems.<\/li>\n<li><strong>TPM<\/strong>: Trusted Platform Module; a secure cryptoprocessor for key storage and integrity measurements.<\/li>\n<li><strong>vTPM<\/strong>: Virtual TPM device exposed to a VM.<\/li>\n<li><strong>PCR (Platform Configuration Register)<\/strong>: TPM registers used to store cryptographic measurements of software\/components loaded during boot.<\/li>\n<li><strong>Measured Boot<\/strong>: Process of hashing\/measuring boot components and extending values into TPM PCRs.<\/li>\n<li><strong>Integrity Monitoring<\/strong>: Capability to surface VM boot integrity signals for monitoring\/alerting.<\/li>\n<li><strong>MIG (Managed Instance Group)<\/strong>: Compute Engine feature that manages identical instances from a template with autoscaling and rolling updates.<\/li>\n<li><strong>Instance template<\/strong>: A reusable VM configuration used by MIGs.<\/li>\n<li><strong>IAP TCP forwarding<\/strong>: Secure access method for VMs without external IP addresses.<\/li>\n<li><strong>OS Login<\/strong>: Google Cloud IAM-based SSH access management for Compute Engine.<\/li>\n<li><strong>CMEK<\/strong>: Customer-managed encryption keys, used to control encryption keys for certain resources like disks.<\/li>\n<li><strong>Confidential VM<\/strong>: Compute Engine capability focused on encrypting data in memory (data in use).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Shielded VM is a <strong>Compute Engine security feature in Google Cloud<\/strong> that helps protect VMs from <strong>boot-level compromise<\/strong> using <strong>Secure Boot, vTPM, and Integrity Monitoring<\/strong>. It matters because bootkits and rootkits can persist stealthily and evade many traditional controls.<\/p>\n\n\n\n<p>In the Google Cloud Compute ecosystem, Shielded VM fits as a <strong>secure-by-default baseline<\/strong> for VM fleets\u2014especially when paired with strong IAM, private networking patterns (like IAP without external IPs), and standardized instance templates.<\/p>\n\n\n\n<p>Cost-wise, Shielded VM is generally part of your Compute Engine usage (verify current pricing), but you should plan for indirect costs such as observability volume and operational response.<\/p>\n\n\n\n<p>Use Shielded VM when you want stronger platform integrity for VM workloads and can validate Secure Boot compatibility. Next, deepen your capabilities by standardizing Shielded VM in templates\/MIGs, integrating integrity signals into alerting\/runbooks, and evaluating complementary controls like OS Login, IAP, and Confidential VM where appropriate.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Compute<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26,51],"tags":[],"class_list":["post-635","post","type-post","status-publish","format-standard","hentry","category-compute","category-google-cloud"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/635","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=635"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/635\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=635"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=635"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=635"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}