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
Split from #7852 (itself split from #7180's provisioning core). #7852 assumed injecting a hosted tenant's database credentials could just call "the generalized broker's issue/revoke path" — but #7174 only generalized the storage layer (orb_enrollments.secret_type discriminator). brokerOrbToken's actual mint logic is still 100% hardcoded to GitHub App installation tokens (createOrbInstallationToken) and explicitly rejects any other secretType with unsupported_secret_type. There is also no revoke path of any kind anywhere in this codebase — revoked_at is only ever read (checked in brokerOrbToken), never written by anything. Both of these need to be built before control-plane can inject or revoke a tenant's real database credentials.
Area
src/orb/broker.ts, migrations/ (if revocation needs a new column/index), src/api/routes.ts (if a new admin-facing revoke route is needed).
Proposal
Add a new secret type (e.g. ORB_SECRET_TYPE_TENANT_DB_CREDENTIAL) to the broker, and a real revoke mechanism. Two things the implementer needs to resolve against the actual current code, not just this ticket text:
Store vs. mint. The broker's existing GitHub-token type mints fresh on each call (a short-lived token derived from a stable App credential). A tenant's Neon database password (Real Postgres/Hyperdrive driver for control-plane's provisionDatabase/deprovisionDatabase #7653) is the opposite shape — a fixed credential control-plane already has in hand from provisionDatabase's own output, not something re-derivable on demand. This almost certainly means this secret type should store a given secret value (encrypted at rest, reusing the broker's existing encryptSecret/decryptSecret AES-256-GCM helpers per Generalize src/orb/broker.ts into a multi-secret-type broker shared by ORB + AMS hosted #7174's own design) rather than mint one — confirm this against the broker's actual current mint/cache code before building.
src/orb/broker.ts, src/api/routes.ts (POST /v1/orb/token, POST /v1/internal/orb/enrollments — the existing mint/exchange routes this likely extends)
Boundaries
Broker-side secret type + revoke mechanism only — does not touch control-plane's own injectSecrets/revokeSecrets wiring (separate sub-issue of #7852, blocked on this one).
maintainer-only — secrets custody design touches every tenant's blast radius; no partial/contributor-drafted version merged ahead of full review (same bar #7174/#5225/#4921 were already held to).
Problem
Split from #7852 (itself split from #7180's provisioning core). #7852 assumed injecting a hosted tenant's database credentials could just call "the generalized broker's issue/revoke path" — but #7174 only generalized the storage layer (
orb_enrollments.secret_typediscriminator).brokerOrbToken's actual mint logic is still 100% hardcoded to GitHub App installation tokens (createOrbInstallationToken) and explicitly rejects any othersecretTypewithunsupported_secret_type. There is also no revoke path of any kind anywhere in this codebase —revoked_atis only ever read (checked inbrokerOrbToken), never written by anything. Both of these need to be built before control-plane can inject or revoke a tenant's real database credentials.Area
src/orb/broker.ts,migrations/(if revocation needs a new column/index),src/api/routes.ts(if a new admin-facing revoke route is needed).Proposal
Add a new secret type (e.g.
ORB_SECRET_TYPE_TENANT_DB_CREDENTIAL) to the broker, and a real revoke mechanism. Two things the implementer needs to resolve against the actual current code, not just this ticket text:provisionDatabase's own output, not something re-derivable on demand. This almost certainly means this secret type should store a given secret value (encrypted at rest, reusing the broker's existingencryptSecret/decryptSecretAES-256-GCM helpers per Generalize src/orb/broker.ts into a multi-secret-type broker shared by ORB + AMS hosted #7174's own design) rather than mint one — confirm this against the broker's actual current mint/cache code before building.brokerOrbToken.Deliverables
ORB_SECRET_TYPE_TENANT_DB_CREDENTIAL(naming open to refinement) storable/revocable through the broker, encrypted at rest.brokerOrbTokenor equivalent) treats a revoked enrollment as invalid.Resources
secret_typediscriminator this builds on)src/orb/broker.ts,src/api/routes.ts(POST /v1/orb/token,POST /v1/internal/orb/enrollments— the existing mint/exchange routes this likely extends)Boundaries
Broker-side secret type + revoke mechanism only — does not touch control-plane's own
injectSecrets/revokeSecretswiring (separate sub-issue of #7852, blocked on this one).maintainer-only — secrets custody design touches every tenant's blast radius; no partial/contributor-drafted version merged ahead of full review (same bar #7174/#5225/#4921 were already held to).