Key Lifecycle
What this screen is for
This is the same key lifecycle editor a tenant administrator uses, opened from Platform Policies: two grids of ALLOW and DENY cells, one row per operation and one column per key status, for the key identifier and for its material versions. What the grids mean, how each cell is read against a key's state and what DEFAULT and STRICT contain are described on the tenant page and are not repeated here:
The editor opens in two forms from Platform Policies. Open editor on the Key Lifecycle card opens the deployment lifecycle policy, the ceiling every tenant policy is checked against. The Lifecycle cell of a tenant's row opens that tenant's own policy, with the tenant's name in the breadcrumb. This page is about what differs in each.
What must exist first
Both forms are offered in system context only; opening either while a tenant is assumed returns you to that tenant's dashboard.
- The deployment form needs the permission to read the deployment lifecycle policy to show the grids, the write permission for DEFAULT, STRICT, the cells and Save policy, and the delete permission for Reset to DEFAULT. Without the read permission the screen says you do not have permission to view the deployment lifecycle policy.
- The tenant form uses the tenant lifecycle permissions, read, write and delete, exactly as the tenant's own screen does. A tenant that cannot be loaded is reported as Could not load the lifecycle policy for this tenant, with a way back.
Decisions you make here
Setting the ceiling
The deployment policy is checked against nothing: Save policy stores both grids as they are. Its summary says a tenant may only ALLOW an operation where this policy also allows it, and that is enforced when a tenant saves: a tenant cell set to ALLOW where this policy says DENY, or where this policy has no cell at all, is refused with the offending cells listed. A tenant may always tighten.
Tightening a cell here does not narrow a tenant that already carries a policy of its own. The crypto service enforces a tenant's stored policy as it is, and this policy only where the tenant has none; a tenant whose stored policy now exceeds the ceiling keeps operating under it, and is refused only on its next save. A change here is published to the crypto service before the server answers, and the crypto service drops every policy it holds in memory when it receives it, so the tenants that inherit are evaluated under the new ceiling from their next operation.
A ceiling with fewer rows than the templates
The editor shows only the rows the stored policy has, and a row the ceiling does not declare is DENY in every column. So if the stored ceiling carries fewer rows than the built-in templates, every tenant that presses DEFAULT or STRICT is refused — the template asks for ALLOW on a row the ceiling does not answer at all.
Press DEFAULT here, which loads the full template into the grids, then Save policy — or press Reset to DEFAULT, which stores the full template in one step. Saving a cell change on a grid that is missing rows does not add them.
A new installation is not in this state. The platform stores the built-in DEFAULT template as the ceiling when a deployment has none, so a fresh installation starts with every row the templates need and its tenants can apply DEFAULT and STRICT immediately.
Resetting the deployment policy
Reset to DEFAULT stores the built-in DEFAULT template as the deployment policy, in place of whatever was stored before, and the server answers with the stored policy. The editor shows the DEFAULT grids at once, the card on Platform Policies reads DEFAULT, and the tenants that inherit are evaluated under it from their next operation.
Because a policy is stored, a tenant save after a reset is checked against DEFAULT like any other save; it is never refused for a missing ceiling. Deployment ceiling missing is answered only where no deployment lifecycle policy exists at all — a fault to report, since the platform stores the DEFAULT template as the ceiling whenever a deployment has none.
Editing one tenant's policy
Opened from the table, the editor writes that tenant's own policy under the tenant's permissions and the same rules as the tenant's screen: a save is checked against the ceiling, and the refused cells are listed as alias · DECRYPT on RETIRED. Reset to DEFAULT here deletes the tenant's policy, so the tenant follows the deployment policy, whatever it is. The badge names the policy in effect; it does not say whether the tenant inherits.
When a saved policy takes effect
A deployment save is written to the policy cache and an invalidation is published once the transaction commits; a tenant save evicts that tenant's copy in the crypto service and applies on its next operation. After you go back, the Key Lifecycle card can show the previous template name for up to five minutes, and a tenant's Lifecycle cell for up to a minute.
How it relates to other screens
Both forms are opened from, and return to, Platform Policies:
A tenant administrator edits the same tenant policy on the tenant's own screen, where the ceiling you set here is what a refused save is measured against: