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 APIs	Bucket B — Databases
Mechanism	Agent TLS intercept + auth header rewrite	Agent TCP proxy (localhost listener)
Code changes required	None	Change connection string to `127.0.0.1:{port}`
Source stores	AWS SM, AWS SSM, Azure KV, GCP SM	Any database with credentials in those stores
Protocols	HTTPS	PostgreSQL, MySQL, MongoDB, Redis
Plaintext exposure	Never	Never

Migration phases

Every migration moves through this lifecycle:

pending → discovering → awaiting_review → completed

Status	What’s happening
`pending`	Migration created; discovery job not yet started
`discovering`	Agent or pull worker scanning the secret store for credentials
`awaiting_review`	Discovery complete; items are queued for reviewer decisions (approve / reject)
`completed`	All approved items written to KnoxCall secrets; migration closed
`cancelled`	Migration 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

Provider	API secrets	DB 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

Go to Infrastructure → Secret Store Migrations
Click New Migration
Choose your source provider and bucket type
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

Egress IP Routing & VPN

Bucket A: HTTPS API migration

​Secret Store Migrations overview

​How it works

​Migration phases

​Source stores supported

​Quick start

​Via admin UI

​Via API

Bucket A: HTTPS API migration

Bucket B: Database migration

Agent database proxy protocols

Migration verification

Migrations API reference

KnoxCall agent

Secret Store Migrations overview

How it works

Migration phases

Source stores supported

Quick start

Via admin UI

Via API