Skip to main content

Bucket A: HTTPS API migration

Bucket A handles migrations where your applications call a cloud secret store API (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, AWS SSM) directly over HTTPS. The KnoxCall agent intercepts these calls before they leave the host, rewrites the authentication header, and returns the secret from KnoxCall instead. Your application code does not change.

How it works

The agent acts as a transparent MITM on the loopback interface. The application’s AWS SDK believes it’s talking to AWS Secrets Manager; the agent translates the call to KnoxCall’s API and returns a response in the expected format. No plaintext secret value ever touches disk. The agent holds secrets in memory only for the duration of the intercept.

Supported capture surfaces

Setting up intercept rules

Intercept rules tell the agent which outbound requests to intercept and how to rewrite them.

Via admin UI

  1. Go to Infrastructure → Secret Store Migrations
  2. Open the migration → click the Intercept Rules tab
  3. Click Add rule
  4. Configure:
    • Match host: e.g. secretsmanager.us-east-1.amazonaws.com
    • Match path prefix: e.g. /
    • Rewrite: select the KnoxCall secret to substitute
  5. Save — the agent picks up new rules within 30 seconds

Example rule (AWS SM → KnoxCall)

The response_format field tells the agent to return the value in the format the application expects (AWS SM JSON envelope, plain value, Azure KV JSON, etc.).

Zero-plaintext guarantee

  • The secret value is never written to disk, logged, or stored in the migration_intercept_rules table
  • The agent holds the value in memory only for the lifespan of a single request
  • If the agent process crashes mid-intercept, the application receives a connection error — not a partial or logged secret

Monitoring migration progress

The secret_consumers table tracks discovered workloads that are consuming each migrated secret:
The admin UI shows a consumer count per secret, and highlights any consumers not yet seen through the intercept path.

Migration status progression

Cutover

When the verification dashboard shows all consumers green and all items have been approved:
  1. In the admin UI, click Commit migration (or call POST /admin/migrations/:id/commit)
  2. Wait for the completed status
  3. You can now safely revoke cloud store credentials and remove secrets from the source provider
Do not revoke the cloud store credentials until you have confirmed all application instances are routing through KnoxCall. Intercept rules route live traffic — removing them before cutover confirmation will break applications.

Cancelling a Bucket A migration

You can cancel a migration in pending, discovering, or awaiting_review state:
This removes all intercept rules. Applications revert to direct cloud store access immediately.

Bucket B: Database migration

For database credentials

Migration verification

DNS/TLS probes and safe-to-delete confirmation

Migrations API reference

Intercept rules and migration endpoints

Migrations overview

Back to overview