You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -185,3 +189,14 @@ The verifier performs three main verification steps:
185
189
- Compares against the verified measurements from the quote
186
190
187
191
All three steps must pass for the verification to be considered valid.
192
+
193
+
### Identifying the deployment
194
+
195
+
Beyond pass/fail, the result carries a few descriptive fields so a relying party can apply its own policy:
196
+
197
+
- **`os_image_is_dev`** — `true` for a development OS image, `false` for production. Dev images are built for local testing and are not hardened for production use, so a relying party generally wants to reject them.
198
+
- **`os_image_version`** — the dstack OS version (e.g. `0.5.10`), useful for enforcing a minimum version.
199
+
- **`tee_platform`** — which TEE produced the verified quote: `tdx`, `gcp-tdx`, or `nitro`.
200
+
- **`key_provider`** — the decoded `app_info.key_provider_info` (`{name, id}`); `name` is e.g. `kms` or `local`. A `local` key provider means the CVM is not KMS-backed, which is itself a dev/insecure posture signal. The raw bytes remain in `app_info.key_provider_info`.
201
+
202
+
`os_image_is_dev`and `os_image_version` are read from the image's `metadata.json`, which is part of `sha256sum.txt` and therefore bound to the `os_image_hash` that step 3 verifies against the quote — so they are as trustworthy as the os-image-hash check itself. They are `null` when the platform does not expose them (e.g. GCP TDX / Nitro Enclave) or when the image predates the field (images without `is_dev` are always production).
0 commit comments