Managed Key Backends By Edition
What this screen is for
Managed key backends by Edition maps each licensed Edition — STANDARD, PROFESSIONAL, ENTERPRISE — to the key-protection backend ANKATech operates for the tenants that Edition routes there. It exists only on an ANKA-hosted deployment, and it is not offered on a customer-operated install. This page is short for that reason.
On your install there is nothing for it to map. Every tenant is wrapped by the one backend your environment declared, or by a backend a tenant brought itself; no tenant holds an Edition that routes it elsewhere, so the per-Edition rows would decide nothing.
What must exist first
Nothing, because there is nothing to do here on a customer-operated install. The card is not rendered on the Cryptography & Trust group landing, the sidebar has no node for it, and it is absent from the command palette — the screen is unreachable rather than merely empty. Reaching its address by hand returns you to the group landing.
The permissions this screen would need on an ANKA-hosted deployment — reading the per-Edition backends, held by the built-in platform administrator, auditor and viewer roles, and managing them, held by the platform administrator alone — change nothing on yours. The platform refuses the underlying requests there whatever permission you hold, stating that the surface does not exist on this deployment model rather than that your access is insufficient.
Decisions you make here
None on a customer-operated install
This screen has no configuration values of its own; the settings rows it would read live under HSM / Cloud KMS and are inert here. No control is offered and no request is issued.
On your install the rotation period of your tenants' key-encryption keys is set on the HSM / Cloud KMS screen, for the backend your environment declared.
On an ANKA-hosted deployment: each tier's key-encryption key rotation
Below the tiers, Tenant key-encryption key rotation lists the three tiers with their backend, who rotates their tenants' key-encryption keys, and the period. A tier on a PKCS#11 HSM is rotated by the platform, online, at its period: a whole number of months from 1 to 24, 12 by default, which you change and save per tier with the permission to manage key custody.
A tier on a cloud key service shows Set by the provider: the provider rotates that key material itself, and no period is offered. A value outside 1 to 24 is refused, because a key-wrapping key's cryptoperiod is bounded at two years.
The period applies to every tenant on the tier. To rotate one tenant's key-encryption key now, or to re-key it after a suspected compromise, use Key custody in that tenant's drawer on the Tenants screen. Changing which Edition a tenant holds, once it has keys, records a key custody move that is planned there too.
On an ANKA-hosted deployment that publishes on RapidAPI: keep all three tiers active
A RapidAPI marketplace tenant follows its subscription plan: the plan sets its Edition, and with it the tier that protects its keys. Its drawer shows the Edition as set by the marketplace plan, and the Edition cannot be assigned or cleared there. When the plan changes and the tenant already holds keys, the platform schedules the key custody move itself.
A plan is never served under another Edition. While a tier is not active, or its backend is full, the subscribers whose plan maps to that tier are refused, and nothing is created or changed for them. Keep the three tiers active, with room for the subscribers of each Edition, for as long as the deployment publishes on RapidAPI.
How it relates to other screens
The backend that actually wraps your tenants' key material, and the one place it is declared and activated, is the HSM / Cloud KMS screen — including the per-tenant tab where a tenant is given a backend of its own:
The Edition a tenant carries is read from the deployment licence, which on a customer-operated installation selects no key backend: