Renamed 2026-05-03. This feature was previously called Databases. The old /v1/databases/* and /admin/databases/* paths now return 404 — use /v1/dyn-db-credentials/* and /admin/dyn-db-credentials/*. The “Databases” name has been freed for the upcoming Database Proxy product (a TCP-level Postgres / MySQL wire-protocol proxy).

Dynamic DB Credentials overview

KnoxCall’s Dynamic DB Credentials feature lets you mint short-lived database credentials on demand — for engineers, CI pipelines, scheduled jobs, or any workload that needs temporary DB access without sharing a long-lived password. You register a database connection once. After that, callers ask KnoxCall for a credential whenever they need one. KnoxCall mints a fresh username + password (or an AWS auth token), tracks it as a lease, and automatically revokes it at expiry.

Why use it

Problem	Without KnoxCall	With KnoxCall
Engineers share a Slack-pinned `prod_password`	Anyone who joins/leaves the team triggers a rotation	Each engineer mints their own 1-hour credential
CI pipeline holds a service-account secret	Leak = full DB compromise until rotation	Leak = ≤ TTL until auto-revoke
Audit trail of “who ran what against prod”	Best-effort, by IP	Per-credential, per-lease, in audit log
Onboarding a contractor for 2 weeks	Manual create + reminder to delete	Set TTL = 14 days, drops itself

How it works

Register a connection — point KnoxCall at your database (Postgres, MySQL, or MongoDB). Pick one of four authentication modes.
Define a role — an SQL template that describes the kind of user to mint (read-only, read-write, or your own template). Built-in readonly / readwrite templates work for most setups.
Mint a credential — call POST /v1/dyn-db-credentials/{name}/creds/{role} with an OAuth access token (or legacy API key — see Authentication). Get back a username + password + expiry.
Use it — connect with the returned credentials like any other DB user.
Forget it — at the lease’s expiry, KnoxCall drops the user automatically. Or revoke it explicitly with POST /v1/dyn-db-credentials/leases/{id}/revoke.

Quick start (UI)

Go to Dynamic DB Credentials in the admin UI and click New Connection.
Fill in the connection details. Test the connection — KnoxCall verifies it can reach your DB before letting you save.
After creation, expand the connection and click Register role → pick readonly or readwrite.
Click Mint credential to issue your first short-lived user.

Quick start (API)

All responses use the standard { data: ..., meta: { request_id: "..." } } envelope. The examples below show the data fields.

# Mint a 1-hour OAuth token (client_credentials) — see /api-reference/authentication
TOKEN=$(curl -s -X POST https://api.knoxcall.com/oauth/token \
  -u "$KNOXCALL_CLIENT_ID:$KNOXCALL_CLIENT_SECRET" \
  -d "grant_type=client_credentials" | jq -r .access_token)

# 1. Register a connection
curl -X POST https://api.knoxcall.com/v1/dyn-db-credentials \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "postgres-prod",
    "engine": "postgres",
    "host": "db.example.internal",
    "port": 5432,
    "admin_username": "kc_admin",
    "admin_password": "...",
    "execution_mode": "direct",
    "default_ttl_seconds": 3600,
    "max_ttl_seconds": 86400
  }'

# 2. Register a role (built-in readonly template)
curl -X POST https://api.knoxcall.com/v1/dyn-db-credentials/postgres-prod/roles \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "name": "analytics_ro", "template": "readonly" }'

# 3. Mint a credential
curl -X POST https://api.knoxcall.com/v1/dyn-db-credentials/postgres-prod/creds/analytics_ro \
  -H "Authorization: Bearer $TOKEN"
# → data: { "username": "kc_user_...", "password": "...", "expires_at": "...",
#           "lease_id": 42, "connection_name": "postgres-prod", "role_name": "analytics_ro" }

Supported engines

Engine	API value	Direct	Agent tunnel	SSH tunnel	IAM (RDS)
PostgreSQL	`postgres`	✅	✅	✅	✅
MySQL	`mysql`	✅	✅	✅	✅
MongoDB	`mongo`	✅	✅	✅	❌ (not RDS)

See authentication modes for what each mode means and when to pick it.

Built-in role templates

Template	Postgres	MySQL	MongoDB
`readonly`	`GRANT SELECT ON ALL TABLES`	`GRANT SELECT`	`read` role
`readwrite`	`GRANT SELECT, INSERT, UPDATE, DELETE`	`GRANT SELECT, INSERT, UPDATE, DELETE`	`readWrite` role

Both templates create a user with the password KnoxCall generates and grant just enough permissions for the named scope. If neither fits, supply your own creation_sql + revocation_sql.

Who can issue a credential

Issuing a credential from the dashboard creates a live username and password on your database, so it is a reveal. In the dashboard this is a Class B reveal: only an Owner or an Admin can do it (an Editor cannot, even with Reveal secrets turned on; that setting covers secret values, certificates and credentialed workflow tests only), and every use asks for a fresh second factor (an authenticator code, a passkey or a security key; an emailed code does not count). Each use writes a plaintext.reveal entry to the audit log before anything is shown, and counts against the same per-person reveal budget as showing a secret’s value (60 per 5 minutes). If the audit entry cannot be written, or the budget cannot be counted, the request is refused rather than served. On the Management API (/v1) a credential still needs the matching permission, and a token issued to a person never carries dyn_db_cred:mint. Registering connections and roles and revoking leases are unchanged.

​Dynamic DB Credentials overview

​Why use it

​How it works

​Quick start (UI)

​Quick start (API)

​Supported engines

​Built-in role templates

​Who can issue a credential

​Next steps