Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.knoxcall.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Secret Store Migrations overview

If your secrets currently live in AWS Secrets Manager, AWS SSM Parameter Store, Azure Key Vault, or GCP Secret Manager, the Secret Store Migration feature lets you move them into KnoxCall — without changing application code and without any secrets ever touching disk during the migration. The goal: KnoxCall becomes the single place your team manages, audits, and rotates credentials, regardless of which cloud provider currently holds them.

​
How it works

The KnoxCall agent runs alongside your applications. During a migration, the agent acts as an intermediary:
  • Bucket A (HTTPS APIs): the agent intercepts API calls your application makes to the cloud secret store, rewrites the authentication, and forwards the secret from KnoxCall instead. No code change in your app.
  • Bucket B (Databases): the agent binds a local TCP port on 127.0.0.1. Your application connects to 127.0.0.1:{port} instead of the database host directly. The agent handles all authentication to the real database and pipes the connection through.
Bucket A — HTTPS APIsBucket B — Databases
MechanismAgent TLS intercept + auth header rewriteAgent TCP proxy (localhost listener)
Code changes requiredNoneChange connection string to 127.0.0.1:{port}
Source storesAWS SM, AWS SSM, Azure KV, GCP SMAny database with credentials in those stores
ProtocolsHTTPSPostgreSQL, MySQL, MongoDB, Redis
Plaintext exposureNeverNever

​
Migration phases

Every migration moves through this lifecycle: 
pending → discovering → awaiting_review → completed
StatusWhat’s happening
pendingMigration created; discovery job not yet started
discoveringAgent or pull worker scanning the secret store for credentials
awaiting_reviewDiscovery complete; items are queued for reviewer decisions (approve / reject)
completedAll approved items written to KnoxCall secrets; migration closed
cancelledMigration cancelled by operator
You can cancel a migration in the pending, discovering, or awaiting_review phase. Once completed, the migration is terminal.

​
Source stores supported

ProviderAPI secretsDB credentials
AWS Secrets Manager✅ Bucket A✅ Bucket B
AWS SSM Parameter Store✅ Bucket A—
Azure Key Vault✅ Bucket A✅ Bucket B
GCP Secret Manager✅ Bucket A✅ Bucket B

​
Quick start

​
Via admin UI

  1. Go to Infrastructure → Secret Store Migrations
  2. Click New Migration
  3. Choose your source provider and bucket type
  4. Follow the setup wizard

​
Via API

curl -X POST https://api.knoxcall.com/admin/migrations \
  -H "Authorization: Bearer $KC_ADMIN_JWT" \
  -H "Content-Type: application/json" \
  -d '{
    "provider": "aws_sm",
    "mode": "pull",
    "credentials": {
      "role_arn": "arn:aws:iam::111122223333:role/KnoxCallMigrationReader",
      "external_id": "your-chosen-external-id"
    },
    "scope": {
      "regions": ["us-east-1"]
    }
  }'
Provider values: aws_sm, aws_ssm, azure_kv, gcp_sm. Mode values: pull, capture, both. Static credentials (access_key_id, client_secret, etc.) are rejected — use IAM role assumption or WIF. See the Migrations API reference for full field documentation per provider.

Bucket A: HTTPS API migration

Zero-plaintext cutover for HTTP/HTTPS secret store consumers

Bucket B: Database migration

Localhost TCP proxy for database credential migration

Agent database proxy protocols

Technical reference for PostgreSQL, MySQL, MongoDB, Redis wire protocols

Migration verification

DNS/TLS probes, operator confirmation, and safe-to-delete status

Migrations API reference

Full endpoint reference

KnoxCall agent

Install and configure the self-hosted proxy agent