Skip to content

Hardening

Statement

ClaimGuard's production VM (the production VM) is a Google Cloud Deep Learning VM (DLVM) image with a documented incremental-hardening plan against it. The host runs with up-to-date OS packages, on the least-privilege the workload service account service account (swapped 2026-05-02), with Shielded VM Secure Boot enabled (also 2026-05-02), and is operated through IAP-SSH rather than direct sshd. The remaining host-level hardening step — OS Login — is queued for plan step the OS Login step, deferred because it requires dev-team coordination (re-keying laptops + osLogin grant management).

The hardening baseline is operating today. The remaining host-level hardening item — OS Login — is yet enforced. Secure Boot and the SA swap, previously listed here as known gaps, landed 2026-05-02.

Implementation

Host configuration today

  • Image: Google Cloud Deep Learning VM image (Linux). Standard GCP-managed kernel; package updates land via the standard unattended-upgrades / apt flow.
  • Shielded VM:
  • vTPM: on.
  • Integrity monitoring: on.
  • Secure Boot: on (enabled 2026-05-02 in the Secure Boot step maintenance window combined with the SA-swap step).
  • OS Login: off at the project metadata level (queued for the OS Login step); SSH today uses metadata-keyed access on top of IAP.
  • Service account: the VM runs under the workload service account (least-privilege), swapped from the default Compute SA on 2026-05-02 ( the SA-swap step combined with the Secure Boot step). Per-secret secretAccessor bindings only; no project-level roles/editor. See Privileged access.

Process posture

  • pm2 as the process supervisor. Crash-restart, log rotation, and pm2 resurrect on boot via the <PM2_SYSTEMD_UNIT> systemd unit (wired 2026-05-02 — until then the dump existed but no boot-time trigger fired it, which surfaced when Tier D rebooted the VM).
  • Application boot depends on JWT_SECRET and other secrets; server refuses to start if they're unset. In production these values are fetched from GCP Secret Manager at backend boot (USE_SECRET_MANAGER=1 activated 2026-05-03). See Secrets management.
  • No server-side admin daemons beyond what the application requires. No RabbitMQ, no Redis, no Elasticsearch on this VM.

Firewall and SSH

  • No public SSH endpoint. SSH is gated through GCP's IAP. See Privileged access for the IAM side, Network security for the firewall side.
  • No legacy world-open SSH rules. The duplicated a legacy SSH firewall rule / the default SSH firewall rules were deleted on 2026-04-28 ( an early plan step).

Logging and monitoring

  • Cloud audit logs for every privileged action. 400-day immutable retention. See Audit logging (cloud).
  • Application logs via pm2 stdout / stderr capture, rotated locally. Not yet shipped to Cloud Logging — cross-listed on Application audit logging.
  • Integrity monitoring signals are visible in the GCP console but not yet wired into a paging channel — queued.

What hardening looks like in practice today

  • the SA-swap step + the Secure Boot step ran together in a maintenance window 2026-05-02. Total observed downtime: ~6 minutes. Pre-window boot-disk snapshot (a pre-change snapshot) was taken as failsafe and remains in place during the soak period.
  • the OS Login step (OS Login) is the remaining bundle item, deferred because it disables the existing metadata-keyed SSH path used by the dev team — needs each operator's laptop re-keyed + osLogin grants managed. Will be scheduled once the team is ready to absorb the change.

What's deliberately not in scope for this page

  • VM-level antivirus / EDR. Out of scope for a Linux GCP VM at this stage.
  • CIS-benchmark scanning. Not running today; revisit at SOC 2 Type II.
  • Container hardening. The application does not run in containers on this VM; tools/services are pm2-managed processes. Container hardening becomes a relevant control if a future architecture introduces them.

Status

implemented — verified 2026-05-06. DLVM image, Shielded VM Secure Boot, least-priv runtime SA, IAP-only SSH, pm2 systemd auto-resurrect, Secret Manager bootstrap active, Cloud audit logging live with long-retention archive. Known gaps below are roadmap items.

What's in place:

  • DLVM image with current OS package state.
  • Shielded VM features (vTPM, integrity monitoring, Secure Boot) enabled. Secure Boot landed 2026-05-02 in the Secure Boot rollout window.
  • VM runs under least-privilege the workload service account SA (swapped 2026-05-02 in the SA-swap rollout window).
  • IAP-only SSH; no world-open SSH or RDP.
  • pm2 startup wired to systemd (<PM2_SYSTEMD_UNIT>) 2026-05-02 — future reboots auto-resurrect the application processes.
  • Documented, reproducible boot path; Secret Manager bootstrap active in production (gate flipped 2026-05-03 — see Secrets management).
  • Cloud audit logging on every privileged action.

Known gaps

  • OS Login is off — plan step the OS Login step. Until enabled, SSH metadata-keyed access lives on top of IAP, and stale home directories for removed users persist on the VM. (The corresponding metadata ssh-keys entries for those removed users were cleaned up 2026-05-02; on-disk dirs remain.)
  • Integrity-monitoring signals are not wired into alerting.
  • No CIS-benchmark scan or routine OS-level vulnerability scan beyond the GCP-managed package update flow.

Roadmap

  • the OS Login step (OS Login enable) — needs dev-team re-keying coordination. Closes the metadata-keyed SSH path + enables cleanup of stale home dirs.
  • CIS-benchmark scan at SOC 2 Type II preparation time.
  • Integrity-monitoring alert pipeline wired into the eventual audit-log alerting infrastructure (cross-listed on Incident response).
  • Container hardening framework if and when the architecture introduces containers.