Skip to main content

POST /admin/migrations

Create a new migration / discovery job. KnoxCall runs a live probe against the provider before persisting — if the federation grant is broken, the request fails immediately with 400 and nothing is stored. Auth: requireOwnerOrAdmin — no step-up required.

Request body

credentials by provider: Static credential fields (access_key_id, secret_access_key, client_secret, private_key, service_account_json, etc.) are rejected at the API level with 400.

Federation subject

KnoxCall signs a short-lived OIDC assertion that your cloud provider validates against its trust policy. The sub claim is specific to your tenant:
Configure that exact value — Azure’s federated-credential Subject, or a GCP WIF attribute condition such as attribute.sub == "knoxcall-migration:<your-KnoxCall-tenant-id>". The New Migration page shows the correct string for the tenant you are signed into.
Earlier connections were told to trust the bare constant knoxcall-migration, which was identical for every KnoxCall customer — any KnoxCall tenant’s assertion satisfied a trust policy naming it. Existing migrations keep working on the old subject, but update your trust policy to the tenant-specific value. The assertion also carries a knoxcall_tenant_id claim you can gate on immediately if you would rather add an attribute condition than re-cut the subject.
scope by provider:

Response