List cluster-CA rotations, newest first.
curl --request GET \ --url https://stratum.example.com/v1/admin/pki/rotations \ --header 'Authorization: Bearer <token>'. Install-scope; gates on pki:DescribeClusterCA — the same action
as the PKI view, since a rotation record is read-only posture and exposes no
key material.
Authorizations
Section titled “Authorizations”Responses
Section titled “Responses”Rotations, newest first.
object
One staged cluster-CA rotation. Rotation cannot be a single action: republishing the CA invalidates every certificate issued under the previous root, so it runs as a sequence with a barrier, driven by a leader-gated reconciler. This record is where that sequence has got to.
object
rot-<base32:10>.
Where the rotation has reached.
minting— the incoming root is being generated and staged. Nothing trusts it and nothing signs with it.distributing— waiting for EVERY node’s CA consumers to have been driven onto both roots. The barrier gates on reload evidence, not on the bundle being present on disk: a root a daemon has not read changes nothing, and advancing early issues certificates a node cannot verify.reissuing— waiting for every node’s transport leaf to be re-issued under the incoming root.cutting-over— signing moves to the incoming root. The point of no return; abort is unavailable from here.retiring— the outgoing root is dropped from the fleet’s trust.complete/failed/aborted— terminal.
The operator’s note recorded when the rotation was started.
SHA-256 colon-hex of the root being replaced.
SHA-256 colon-hex of the replacement root. Empty until minting has published it — recorded only after the material exists, so the record can never name a root that was never published.
Whether this rotation can still be abandoned. True only before cutting-over, while the cluster still signs with the outgoing root so walking away leaves it exactly as it started. After cutover, going back is a second rotation rather than a cancellation.
Nodes currently holding the barrier shut — those whose CA consumers have not been driven onto the incoming root (or, at reissuing, whose leaf is not yet re-issued), followed by any whose reports have gone stale. A stale node blocks rather than passes: unknown is not agreement.
When the CURRENT phase began. “Distributing for three days” is the fact worth alerting on, not “started three days ago”.
Example
{ "items": [ { "phase": "minting" } ]}Authenticated but not authorized.
object
The findings of a rejected IAM policy document (custom and resource policies).
One finding of a rejected IAM policy document. A rejection lists every finding, so the author fixes the document in one round trip.
object
The finding, e.g. INVALID_DOCUMENT, UNKNOWN_ACTION, ACTION_NOT_APPLICABLE.
Index of the statement at fault; -1 for the document as a whole.
The offending action, where one is at fault (ACTION_NOT_APPLICABLE).
Field errors, for codes that carry them: each problem at its field
(see FieldError). Documented on the responses that set it, e.g.
approveNodeJoin’s INVALID_INPUT and JOIN_APPROVAL_REFUSED.
Absent otherwise.
One field’s problem, the stage-2 installer API’s shape.
field is the field’s path, message what is wrong with it.
object
The field’s path, e.g. links[0].interface, disks[1].confirm,
mgmt.address or role; empty for the whole request.
Structured facts about the refusal, for codes that carry them. The
shape is fixed per code and documented on the response that answers
it, e.g. IMAGE_POOL_MISMATCH (see ImagePoolMismatchDetails) and
IMAGE_IN_USE. Absent for codes that carry none.
object
Example
{ "issues": [ { "code": "ACTION_NOT_APPLICABLE", "action": "compute:CreateVpc" } ]}