Platform Administrative Workloads
What this screen is for
This screen, opened by the Administrative Workloads entry of the platform sidebar, lists the administrative workloads of the platform: the pipelines and jobs that administer the installation itself without a person, such as a release pipeline or a job that provisions tenants. It is offered on every deployment model.
It is the tenant screen on the platform plane: the same list, the same detail with its tabs Info, Keys, Federated identities, Scopes and Activity, and the same controls, each gated on its platform permission. This page covers only what differs.
What must exist first
- A platform administrator, working in the platform context. Any other role is told the screen is not theirs, and nothing is requested. Opening it while you are inside a tenant sends you to that tenant's workloads screen.
- The permission to read the platform's administrative workloads, and for each control the platform permission that matches it: create, update, revoke, manage credentials, assign scopes.
- For a federated identity, a trusted issuer the deployment itself declares. That registry exists only on an installation you operate yourself; on an ANKA-operated installation a platform workload signs in with a registered key.
Decisions you make here
The first platform workload
A platform workload can be registered here like any other. When the installation's automation must start before anyone signs in to the console, the environment host can register the first one instead: envctl.sh <env> workload-bootstrap creates an ACTIVE platform workload with a key it generates for the run. It registers nothing while any platform workload that is not REVOKED exists, a SUSPENDED one included.
What a platform workload may hold
Assign scopes offers only the scopes the platform lists as assignable by you. A platform workload, unlike a tenant's, may hold platform scopes and the management of tenant workloads. It never holds the management of platform workloads: a person creates, changes and revokes them, so no workload can create or empower another platform workload.
The rest of the tenant rules hold here too. A platform workload never holds a cryptographic data-plane scope, quorum decisions, account recovery, tenant identity-provider or tenant notification-delivery writes, dangerous settings or deployment secrets; you must hold every scope you assign and every scope the workload holds today; and a workload never changes itself.
Containing a platform workload
A platform workload can act across the installation, so contain it as soon as it is in doubt. Revoke on a key, Suspend and Revoke workload act exactly as they do for a tenant's workload: each refuses the workload's tokens at once. Suspending removes authority and confers none, so you may suspend a workload whatever scopes it holds.
Undoing a suspension is not symmetrical. Reactivate gives the workload back everything it can do, so you must hold every scope it holds. Revoke workload cannot be undone at all.
Bringing back the platform automation workload
The platform automation workload is the one envctl.sh <env> workload-bootstrap registered. In a development deployment (created with --app-env dev) it also holds tenant-plane scopes that no platform administrator holds, so once it is suspended there, nobody can reactivate it from this screen. The way back is on the environment host: sudo envctl.sh <env> workload-recovery. It acts only on a SUSPENDED workload, and in one step it:
- generates a new key on the host;
- reactivates the workload;
- revokes every old key;
- removes every federated issuer binding;
- leaves its scopes unchanged.
The recovery is recorded in the audit trail with the environment host as the actor, and records key fingerprints only, never a key. Binding a federated identity to the workload again afterwards is an ordinary act on this screen. In any other deployment the platform super administrator role holds every scope of that workload, so a super administrator brings it back with Reactivate here.
Reviewing a platform workload's activity
The Activity tab, last in the detail, shows what was done to the platform workload, to its keys and to its federated identities, in one list with the newest first, a federated identity that has since been unbound included. Every entry names the platform administrator or workload that acted, in full. It needs the permission to read the platform's administrative audit trail.
The tab states what it covers: entries for a key or a federated identity recorded before release 3.4.1 do not name their workload and are not listed here. A read that fails is stated as an error, never shown as an empty history. The tab offers no View in Audit Log link on the platform plane; the Global Audit Log holds the same entries.
How it relates to other screens
The issuers a platform workload may be bound under are declared on the deployment's workload identity screen:
The people who administer the platform, and the roles they hold, are managed on their own screens:
A request a platform workload makes that needs approval is decided here, by a person:
What each workload did is in the audit trail, under its name: