Skip to content

Confidential SuperAdmin Provisioning

Akshaya Admin does not expose public administrator registration or bootstrap APIs. The first SuperAdmin is provisioned only by an operator with repository access, Cloudflare credentials, and D1 access.

Security boundary

  • GET /api/auth/bootstrap-status returns 404 at the public Admin Worker boundary.
  • POST /api/auth/bootstrap returns 404 at the public Admin Worker boundary.
  • The Admin React application contains no bootstrap-status call, bootstrap-token field, first-admin form, or browser bootstrap submission path; it always presents normal Admin sign-in when there is no authenticated Admin session.
  • The public Admin account navigation points to the group-wide /login/ routing hub instead of advertising separate Customer/Freelancer login links.
  • The first administrator is created directly in D1 by the operator-only seed command.
  • The plaintext password is read only from the local process environment. It is never written to D1, the repository, a generated SQL file, or a command-line argument.
  • The seed stores a random 16-byte salt and a PBKDF2-SHA256 256-bit password hash using 120,000 iterations, matching the Admin Worker verifier.
  • The seeded identity receives role='Admin', status='Active', and an admin_access row with access_level='SuperAdmin'.
  • The command refuses to run when any Admin already exists. Additional administrators must be managed through authenticated Admin RBAC controls.
  • Admin MFA remains independent. After the first login, enroll MFA immediately from the Admin security controls.

Prerequisites

  1. Apply all D1 migrations, including the unified auth and Admin RBAC migrations.
  2. Authenticate Wrangler to the intended Cloudflare account.
  3. Confirm apps/admin-web/wrangler.jsonc points to the intended production D1 database.
  4. Run this only from a trusted operator workstation. Do not place the seed password in shell history, source control, CI variables used by untrusted jobs, screenshots, tickets, or chat.

Seed the first SuperAdmin

Set the three process environment variables and run the seed command.

PowerShell

$env:AKSHAYA_ADMIN_EMAIL = "admin@example.com"
$env:AKSHAYA_ADMIN_NAME = "Akshaya Administrator"
$env:AKSHAYA_ADMIN_PASSWORD = Read-Host "Initial Admin password"
npm run seed:admin:superadmin
Remove-Item Env:AKSHAYA_ADMIN_PASSWORD

Use a unique production email and a strong password. The password must be 12-128 characters and contain at least one letter and one number.

What the command verifies

Before writing, the script confirms:

  1. no Admin account already exists;
  2. the requested email is not already assigned to another user;
  3. D1 is reachable with the configured Wrangler environment.

After writing, it reads the seeded identity back and requires all of these values before reporting success:

  • role = Admin
  • status = Active
  • access_level = SuperAdmin

If post-seed verification fails, the script performs a best-effort cleanup of the exact newly-created Admin identity.

First-login checklist

  1. Open the production Admin portal.
  2. Confirm the page presents only the standard Admin email/password sign-in flow and never a first-admin/bootstrap form.
  3. Sign in with the seeded account.
  4. Confirm the Admin workspace loads successfully.
  5. Enroll MFA immediately and save recovery codes securely.
  6. Sign out and sign back in to verify the MFA challenge.
  7. Confirm /api/rbac/me reports the expected SuperAdmin access.
  8. Confirm both historical bootstrap endpoints continue to return 404.

Regression controls

Automated tests protect both layers of the confidential provisioning boundary:

  • Worker-boundary tests require the historical public bootstrap endpoints to stay 404.
  • Admin source tests reject reintroduction of bootstrap-status calls, browser bootstrap submissions, ADMIN_BOOTSTRAP_TOKEN, bootstrap-token inputs, or first-admin setup wording.

Do not re-enable browser bootstrap

ADMIN_BOOTSTRAP_TOKEN, a browser bootstrap form, or a public first-admin endpoint must not be reintroduced. Disaster recovery should restore D1 from backup or use a reviewed operator-only recovery procedure, not public registration.