Account
Security
API tokens and their scopes, team roles and permissions, sessions, support access with customer consent, the hash-chained audit log, and single sign-on.
API tokens#
API tokens let scripts, the CLI, Terraform and AI assistants act on your account. Create them under
Settings → API tokens (owners and admins). A token is shown once, as act_…; only its SHA-256 hash is stored.
curl https://cloud.ankra.app/v1/servers -H "Authorization: Bearer act_..."
A token acts as the account and the user who created it, with that user's current role: demoting or removing the
user narrows or ends what the token can do. Tokens need no CSRF header. Every action taken with a token is recorded in
the audit log with (via API token <name>).
Scopes#
| Scope | Allows |
|---|---|
read |
Every read the user's role allows; 403 on every write. |
read_write |
Everything the user's role allows. |
a list, e.g. read,operate,self |
Exactly the routes guarded by the listed permissions, from read, operate, billing.read, billing.manage and self. A list always includes read and self. |
A read-only token (read, or a list with neither operate nor billing.manage) never reads secrets: database
credentials, object storage keys, kubeconfigs and Kubernetes tokens, the console, instance metadata and payment
methods answer 403 with reason: read_only_token_cannot_read_credentials. Use a token with a write scope for those.
tokens.manage and members.manage can never be granted to a token: managing tokens, members and support access
needs a signed-in session. A leaked token therefore cannot mint another token or invite anyone.
Expiry#
Every token expires: after 90 days by default, or at an expires_at you choose up to 365 days ahead. last_used_at
shows when it was last used (updated at most once a minute). Revoke a token at any time from the same page.
Team roles#
Invite people under Settings → Members. Every user has one role:
| Permission | Covers | owner | admin | member | viewer |
|---|---|---|---|---|---|
read |
every read of resources, operations, the catalogue, audit and members | ✓ | ✓ | ✓ | ✓ |
operate |
creating, changing and deleting resources | ✓ | ✓ | ✓ | — |
members.manage |
inviting, changing roles, removing members, support access | ✓ | ✓ | — | — |
tokens.manage |
listing, creating and revoking API tokens | ✓ | ✓ | — | — |
billing.read |
usage, invoices, credits and payment methods | ✓ | ✓ | — | — |
billing.manage |
payment methods and coupons | ✓ | ✓ | — | — |
self |
your own sessions | ✓ | ✓ | ✓ | ✓ |
- Each account has exactly one owner, the person who created it. Nobody can remove the owner, change the owner's role or make someone owner through the API.
- Admins manage members and viewers and may promote a member to admin, but only the owner demotes or removes an admin.
- Invitations are links valid for 7 days and used once. Removing a member deletes the user, their sessions and their API tokens.
Sign-in and sessions#
- You sign in at cloud.ankra.app with your Ankra account, the one you use for Ankra Platform. Ankra Cloud keeps no password of its own for it, and an invitation is accepted by continuing with the invited email address.
- A session lasts at most 12 hours from sign-in and ends after 60 minutes without activity. Settings → Sessions lists your sessions and signs out the others.
Two-factor authentication#
Turn on an authenticator app (Google Authenticator, 1Password, Authy or any app for six-digit, 30-second codes) under Settings → Security: scan the QR code, enter the first code, and save the ten recovery codes, which are shown once and each work once. From then on every sign-in asks for a code or a recovery code. Five wrong codes lock the second step for a minute, doubling after that. Regenerating recovery codes or turning two-factor authentication off needs a current code or a recovery code.
The account owner can require two-factor authentication for all members; members without an authenticator set one up the next time they sign in, before anything else. The owner turns it on for themselves first. See the two-factor authentication API.
Single sign-on#
Ankra Cloud signs people in through the Ankra identity service (OpenID Connect with PKCE), which is shared with Ankra
Platform: someone signed in to platform.ankra.app is signed in here without another prompt, and signing out of one ends
both. Google, Microsoft and GitHub are offered as one-click sign-in. The control plane requires a verified email and
never stores provider tokens. Linked identities are listed under Settings → Overview → Sign-in methods; unlink one
with DELETE /v1/account/identities/{id} as long as another way to sign in remains.
Support access#
Ankra support staff can only see your account through a support session, and you control it under Settings → Support:
- A read-only session (the default) views the account as a user you name. It cannot change anything, and it cannot read credentials or live views: database passwords, object storage keys, server consoles and payment methods.
- An elevated session can act, but only with your consent: a one-time code you create in Settings → Support (valid 15 minutes to 24 hours) and read to the support engineer, or the owner's standing always allowed setting. Even elevated, no support session ever manages API tokens, members, payment methods or support access.
- Every support session is written to your audit log in the same transaction that opens it (
support.session_started, with the staff member, the mode and the reason), and every staff read of your data is recorded asstaff.read. - Settings → Support lists open sessions, and you can end any of them at once.
- Sessions last at most one hour and end immediately when the staff member's access is revoked.
Audit log#
Every action by users, API tokens, support staff, operators and the system is recorded: creations and deletions,
sign-ins and failed sign-ins, lockouts, refused requests (access.denied, auth.csrf_rejected), token use, session
revocations and audit exports. Each entry carries the actor, the action, the resource, the outcome (success,
denied or failed), the client address, the user agent and the request id that the API also returned in
X-Request-Id. See it under Activity in the console or with GET /v1/audit.
Tamper evidence#
The log is append-only and hash-chained per account. Each entry's entry_hash is a SHA-256 over its canonical
JSON, and previous_hash names the entry before it, so changing or removing any row breaks the chain. The database
refuses updates and deletions of audit rows, and Ankra re-verifies every chain hourly.
Check your chain at any time:
curl https://cloud.ankra.app/v1/audit/integrity -H "Authorization: Bearer $ANKRA_CLOUD_TOKEN"
{ "status": "verified", "head_sequence": 1841, "verified_through_sequence": 1841, "verified_at": "…", "pruned_through_sequence": 0, "break": null }
status is verified, unverified (not checked up to the head yet) or broken, with the first break found.
Export#
GET /v1/audit/export streams the log as JSON lines (application/x-ndjson) in chain order, 500 entries per page;
the X-Next-After header gives the after value for the next page and is absent on the last. With the entries in
hand you can recompute every entry_hash yourself and archive the log in your own systems. Starting an export is
itself audited. The CLI has ankra-cloud audit export and ankra-cloud audit integrity.
Entries are kept for 400 days by default; only verified entries are pruned, and chain anchors are kept so what remains
still verifies (pruned_through_sequence says where the kept chain starts).
Infrastructure security#
- Servers are isolated KVM virtual machines. Anti-spoofing on every interface restricts a server to its own MAC and IP addresses.
- Private networks are separate EVPN segments per network.
- Secrets Ankra holds for you (object storage keys, database passwords, backup keys, TLS private keys) are sealed at rest with the control plane's secret key and are never logged.
- The API requires TLS in production, including to its database.