Skip to content

Key Management CLI — Overview

Binary: ankasecure-km
Version: 3.4.0
Java required: 25+ (bundled in installer media)
Get it: Downloads · Installation

The Key Management CLI automates the key management of one AnkaSecure tenant from a shell or a pipeline, as an administrative workload* of that tenant. It is a thin shell over the Key Management SDK: one command per SDK method, the same operations, the same refusals.

It performs no cryptographic operation; encryption and signing are the Runtime CLI's. People administer everything else in the Admin Console: users, roles, tenants, tenant policies, key backends, and the approval or rejection of quorum requests.

1. What it covers

Group Verbs
keys list, get, create, update, import-key, import-keystore, analyze-keystore, export, lifecycle-cause-verdicts, supported-algorithms, suspend, reactivate, revoke, archive
materials list, get, revoke
rotation rotate, admissibility, schedule, replace-schedule, executions
destruction request-key, cancel-key, request-version, cancel-version, orders
quorum-requests list, get, cancel
exchange-contexts list, list-for-application, get, create, update, delete, suspend, resume, close
exchanges list, create, get, update, discard-draft, clone, validate, preview-activation, activate, suspend, resume, revoke
capability-grants list, create, preview, get, delete
constraint-policies list, create, get, update, delete
internal-crypto-use-cases list, create, get, delete, suspend, resume
directory list-applications, get-application, list-actors, list-application-actors, get-actor, list-counterparty-types, get-counterparty-type

Plus init and view-session. Every option is in the Commands Reference.

2. Signing in

ankasecure-km init --url https://api.example.com --workload-id <WORKLOAD_UUID> --private-key-file /etc/acme/workload-key.pem

init takes exactly one credential reference: --private-key-file (a key whose public half is registered on the workload), --token-file or --token-command (a federated token from an issuer the workload is bound to). It authenticates once and stores the address, the workload id and the reference, never a key, token or secret. Every later command signs in again with that reference and holds its DPoP-bound token in memory only.

There is no person sign-in, no session, no context and no --tenant: the workload's token names its tenant. The workload, its key and its scopes are prepared in the Admin Console (Key Management SDK — Prerequisites).

3. Output and exit codes

--format json (the default) prints the response as JSON on stdout; --format table prints a table. A value a newer server adds to an enumerated member (a new key status, for example) is printed as the server sent it, in every format. Exit codes: 0 success (a pending quorum approval included), 1 user error, 2 usage or authentication/authorization failure, 3 other server refusal, 4 IO or network failure (details).

A destruction request, or an operation the tenant's quorum policy gates, prints {"status":"PENDING_APPROVAL","quorumRequestId":...} and exits 0 (details).

4. Security

  • Credential at rest: references only, in an owner-only configuration file; tokens live in memory.
  • Secrets: a keystore password is read from standard input or a no-echo prompt, never from an option value; a new internal cryptographic use case's client secret is printed once and never written to a file or a log.
  • TLS: --insecure disables verification, is persisted, and warns on stderr on every command.
  • A parse error repeats nothing from the command line, so a mistyped secret never reaches a terminal log.

CLI Version: 3.4.0
Last updated: 2026-10-26

* restricted content — see higher-tier documentation