UID2-6717: validate operator key against core service before enclave startup

[sunnywu]

Summary

• Adds OperatorKeyRejectedError (E07) to confidential_compute.py — a new startup error class for when the core service explicitly rejects the operator key.
• Adds validate_operator_key_with_service() called at the end of validate_configuration(), after the existing connectivity check. It POSTs to {core_base_url}/attest with Authorization: Bearer {operator_key} and no attestation payload. The core service authenticates the key before touching the payload, so a 401 → invalid key / 400 → valid key distinction is reliable and stable.
• Non-blocking on connection errors, timeouts, or unexpected HTTP status codes — startup is not gated on the pre-flight check failing for reasons unrelated to the key itself.
• Adds unit tests in scripts/tests/test_confidential_compute.py covering all relevant code paths.

Background

Private operators can misconfigure their key by copying it incorrectly (e.g. I vs l). The existing validations (regex format + env alignment + network connectivity) pass for such keys; the failure only surfaces as AttestationFailure: invalid operator key inside the running enclave, which is hard to diagnose. See UID2-6717 and the originating Slack thread.

How it works

POST {core_base_url}/attest
Authorization: Bearer {operator_key}
Content-Type: application/json
{}

Response	Meaning	Action
401	Key unknown/rejected by auth middleware	Raise E07: OperatorKeyRejectedError, abort startup
400	Key accepted, payload missing (expected)	Log and continue
Other	Unexpected — don't block startup	Log warning and continue

Test plan

• python3 -m pytest scripts/tests/test_confidential_compute.py -v — all 9 tests pass
• Confirm E07 fires when an invalid key is used in a dev deployment
• Confirm normal startup is unaffected with a valid key

🤖 Generated with Claude Code