Administrative Workloads
What this screen is for
This screen, opened by the Administrative Workloads entry of the tenant sidebar, lists the administrative workloads of this tenant: the pipelines and jobs that administer it without a person, such as a provisioning job or a key-rotation pipeline. It answers one question: what can act on this tenant when nobody is signed in.
A workload has no password and no client secret. It signs in with a key pair it holds, of which only the public key is registered here, or with a token its own identity provider issues it. Each token it obtains is bound to the workload and lasts at most five minutes, and it carries only the scopes you assign on this screen.
The list shows every workload of the tenant, revoked ones included, with its status, the number of keys still accepted for it and its scopes. Choose a name to open its detail, where every other control lives, in four tabs: Info, Keys, Federated identities and Scopes.
A workload administers the tenant; it never uses keys. Encrypting, signing and the other cryptographic operations belong to cryptographic actors.
What must exist first
- The permission to read the tenant's administrative workloads; it shows the sidebar entry and the list. Without it the screen says so and requests nothing.
- To create a workload, the permission to create one. To edit, suspend and reactivate it, the permission to update workloads; to revoke one, the permission to revoke workloads.
- To register, rotate and revoke keys and to bind or unbind a federated subject, the permission to manage workload credentials. Binding also needs the permission to read workload identity trust, which lists the issuers you may choose from.
- To assign scopes, the permission to assign workload scopes.
- For a federated identity, at least one trusted issuer that the tenant may bind under. A tenant declares its own issuers in its settings, under Integrations → Trusted issuers; an issuer the deployment declared is offered as well.
Each control appears only with its permission. The platform still decides every change, and a refusal is shown as the platform worded it.
Decisions you make here
Creating a workload
Create workload asks for a name and an optional description. The name uses letters, digits, dots, hyphens and underscores, starting with a letter or a digit, and is unique among the tenant's workloads that are not revoked, compared without regard to case. It is the name the audit trail records for everything the workload does.
A new workload is ACTIVE but can do nothing yet: it has no key, no federated identity and no scope. Give it one way to sign in and the scopes it needs from its detail.
Registering a public key
On Keys, Register public key takes the public JWK of a key pair the workload holds: an EC key on P-256, P-384 or P-521, or an RSA key of 2048 to 4096 bits. The private key stays with the workload. A pasted key that carries any private member is cleared in the browser and never sent; paste the public key only.
The key pair is generated by whoever runs the workload, for an integration its developer, who sends you only the public JWK: you never receive or hold the private key. Once the key and the scopes are in place, give that person the workload's id, shown under its name in the detail.
The key is identified by its thumbprint, shown as Key ID, and one key belongs to one workload in the whole deployment. Valid until is optional: left empty, the key is accepted for twelve months from registration, and no key is accepted for more than twenty-four.
Rotating a key
Rotate on an ACTIVE key registers its successor. The new key is accepted at once; the old one is ROTATING_OUT and still accepted for the Grace period, 0 to 720 hours, 24 when left empty, so the workload can switch keys without an interruption. A grace period of 0 revokes the old key at once and refuses every token the workload holds.
A workload may also hold several active keys at once: register another key instead of rotating when you want both to stay valid.
Binding a federated identity
On Federated identities, Bind federated subject lets the tokens a trusted issuer mints for one exact subject sign the workload in, with no key held by the workload, for example the service account of a Kubernetes job. Choose the issuer and type the subject exactly as the token's sub claim carries it.
One issuer and subject pair signs in as one principal of the tenant: a pair already bound to another workload or to a cryptographic actor is refused. Unbind stops the subject from signing in; tokens it already obtained remain valid until they expire, within five minutes, so suspend the workload when they must be refused at once.
Assigning scopes
On Scopes, Assign scopes offers only the scopes the platform lists as assignable by you, and the set you save replaces the current one. A workload's next token carries the new set.
What you may assign is narrower than what you hold. A workload never holds a cryptographic data-plane scope other than the keystore import, a platform scope, workload management, quorum decisions, account recovery, identity-provider or notification-delivery writes, or an audit scope. You must also hold every scope the workload holds today, so nobody can take over a workload more powerful than themselves. The same rule applies to renaming and reactivating it.
A workload never changes itself: it cannot widen its own scopes, register its own keys or reactivate itself. A person makes those changes.
Containing a workload
When a workload or its key is in doubt, act from its detail:
- Revoke on a key refuses at once every assertion signed with it and every token the workload already holds. The workload's other keys keep working.
- Suspend stops the workload from obtaining tokens and refuses every token it holds, until Reactivate. Tokens refused by the suspension stay refused.
- Revoke workload revokes every key and federated identity with it and refuses its tokens at once. It cannot be undone: the record stays for the audit trail, and its name becomes free for a new workload.
Edit changes the name and the description only; the keys, federated identities, scopes and status do not change.
Requests that need a quorum
When the tenant requires a quorum for an operation, a workload that asks for it does not carry it out: the request waits for approval. Only a person approves or rejects it, never a workload.
How it relates to other screens
The people who administer the tenant, and the roles they hold, are managed on their own screens:
The issuers a workload may be bound under are declared in the tenant's integrations:
Key use belongs to cryptographic actors, which are bound to issuers in the same way:
A request a workload makes that needs approval is decided here:
What each workload did is in the tenant's audit trail, under its name: