This document is written for a security reviewer. It states what the system claims about its own security, points at where each claim is enforced in the code/infra, and gives the exact command to verify it against live state — so no claim here has to be taken on trust. It also lists the honest residual risks and the things we deliberately do not defend against.

Companion reading: README.md (architecture + bring-up), docs/deep-dive.html (threat model, dead ends), broker/README.md (the broker's auth model).

An MDM-enrolled (macOS) or operator-attested (Linux) CI worker fetches its per-role vault.yaml from a brokered Secret Manager over mutual TLS:

worker (SCEP client cert)
  → HTTPS LB  (Cloud Armor + mTLS termination; injects X-Client-Cert-* headers)
    → vault-broker (Cloud Run; validates headers, role-binds, reads the secret)
      → Secret Manager  vault-<role>

The reprovision orchestration (EACS → re-enroll → mint → puppet) is driven by the reprovision CLI, run either directly or by a Puppet-managed on-network runner that Hangar queues jobs to. This document covers the secret-delivery security model; the reprovision safety guards are summarized at the end.

The broker performs no cryptographic validation of its own beyond parsing the leaf cert to read its role. It trusts the load balancer's X-Client-Cert-Chain-Verified header. That is safe only because of two infrastructure facts, and the entire model collapses if either regresses:

1. The LB overwrites the X-Client-Cert-* header names it injects, so an inbound client cannot forge them.
2. The broker is unreachable except through the LB (Cloud Run ingress = internal-and-cloud-load-balancing), so nothing can present hand-crafted headers directly.

Both are verified in the table below (rows H1 and H2). If a reviewer checks nothing else, check those two.

Line numbers are approximate (verify against the current tree); commands assume gcloud config set project relops-bootstrap and appropriate IAM.

These are covered in depth in docs/deep-dive.html §8; summarized here so a reviewer sees them up front rather than discovering them:

• Shared SCEP challenge. One challenge per provisioner, stored in Secret Manager + embedded in the SimpleMDM profile. A leak + MDC1 network access lets an attacker enroll a cert for that role. Bounded by Cloud Armor (N1). Not yet rotated or per-role. This is the lightest crypto in the system.
• step-ca compromise mints any cert → reads any vault. Bounded by IAP-only SSH, no public ingress, encrypted key at rest. Same trust we place in GCP admins fleet-wide.
• Broker compromise reads all vault-* secrets — same blast radius as an operator's 1Password access. Surface kept tiny (≈150 lines, no crypto of its own beyond leaf parsing).
• In-memory rate limit (B4) does not coordinate across Cloud Run instances.
• Linux key on disk. /etc/relops-bootstrap/key.pem (root:root 0600) is copyable by root — but root can already read the resulting vault.yaml.
• CRL / revocation not implemented; 24h cert lifetime is the current bound.

Only the m4 family is live end-to-end (provisioner + populated secret): gecko_t_osx_1500_m4, …_m4_staging, …_m4_no_sip. The six gecko_t_linux_* roles have provisioners but empty secrets (not functional). r8/1015 are not started. Verify:

for s in $(gcloud secrets list --format='value(name)' | grep '^vault-'); do
  echo "$(gcloud secrets versions list "$s" --filter=state=enabled --format='value(name)' | wc -l | tr -d ' ') $s"
done

The cron provisioner (relops-provisioner Cloud Run + relops-provisioner-tick Cloud Scheduler + its SAs, IAM, allowlist/kill-switch secrets, and GCS state bucket) — a superseded path that fired SimpleMDM script-jobs — was decommissioned (2026-07) in favor of the signed PKG + Hangar runner. It is removed from Terraform and torn down in GCP. The shared simplemdm-api-token secret was retained (relocated to terraform/simplemdm_secret.tf). Confirm:

gcloud run services list --format='value(metadata.name)'          # only vault-broker
gcloud scheduler jobs list --location=us-central1                 # empty
gcloud secrets list --format='value(name)' | grep provisioner-    # empty
gcloud secrets list --format='value(name)' | grep simplemdm       # simplemdm-api-token (retained)

terraform plan should be quiet. Two things a reviewer/operator must know:

• The step-ca boot image is pinned to a specific version in step_ca.tf (data.google_compute_image.debian uses name, not family). This is deliberate: a family lookup resolves to the latest image, so every apply would try to replace the CA VM. The CA keys live on a separate prevent_destroy persistent disk (google_compute_disk.step_ca_state, mounted at /home/step) and survive a VM replace, but a replace still swaps the boot disk and changes the internal IP — i.e. takes the CA offline. Bump the pinned image deliberately, never via a family auto-resolve.
• Known benign drift: the live vault-broker service carries an empty scaling {} block not present in config, so plan shows one in-place update (removing min_instance_count/manual_instance_count = 0). It changes no behavior; reconcile it deliberately, not as a side effect of another apply. Until then, prefer -target when applying unrelated changes.

The reprovision pipeline will not wipe a busy worker: quarantine → drain (2 consecutive idle polls) → pre-wipe idle re-check that aborts if a task is running → Bootstrap-Token-escrow guard → EACS with obliteration_behavior=DoNotObliterate (fails safe). See orchestrator/orchestrator/workflow.py (step_drain, step_wipe) and clients/taskcluster.py (is_currently_busy). Secrets are resolved at runtime (env → op:// 1Password → GCP Secret Manager); none are hardcoded (orchestrator/orchestrator/config.py, secrets.py).