Skip to content

Add a tenant-DB-credential secret type + generic revoke path to src/orb/broker.ts #8064

Description

@JSONbored

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_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 codebaserevoked_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:

  1. 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.
  2. Coordinate with Add AMS-specific secret type to the generalized broker (src/orb/broker.ts) #7674 (still open, "Add AMS-specific secret type to the generalized broker"): both issues are adding a new secret-type strategy to the same broker. Land on the SAME generalized mint-vs-store strategy interface so Add AMS-specific secret type to the generalized broker (src/orb/broker.ts) #7674 can plug its own type into it later, rather than each issue inventing its own one-off branch inside brokerOrbToken.

Deliverables

  • A new ORB_SECRET_TYPE_TENANT_DB_CREDENTIAL (naming open to refinement) storable/revocable through the broker, encrypted at rest.
  • A real revoke path: marks the enrollment revoked, and every existing read path (brokerOrbToken or equivalent) treats a revoked enrollment as invalid.
  • The GitHub-token type's existing behavior is completely unchanged — this is additive, not a rewrite.
  • Tests: mint/store, revoke, and revoked-read-fails, without any live secrets or live third-party calls.

Resources

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).

Metadata

Metadata

Assignees

Labels

maintainer-onlyOwner-only work — yields no Gittensor points.

Projects

Status
Done

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions