Skip to main content
Deleting a guest cluster is the one operation in Celum that can require two people: one raises a request, another approves it. Everything else a permission grants happens the moment it is invoked. Requests are reviewed at /iam/approvals, and — when Slack is configured — on an approval card with Approve and Reject buttons in a channel.

​
The flow

A delete that is gated returns 202 with status: approval-required and the request itself — not an error. The cluster is untouched until somebody decides.

​
Who can do what

An API token can never bypass approval, and can never approve. Both are refused at the door: a token’s delete is always accepted as a request for a human, and a token’s approve is rejected with “Deletion requests must be reviewed from an interactive session”.Granting cluster:DeleteWithoutApproval to a token therefore changes nothing. A token that needs to remove clusters unattended cannot be given that ability by permission — the review is a property of the session, not of the policy.
cluster:ListDeletionRequests exists and is carried by two built-in policies, but nothing checks it. The listing endpoint authorises per row — it returns the requests you raised plus the ones you may approve — so the action is there to keep policy validation from rejecting a name the platform itself hands out, not to gate anything.

​
A request

A rejection without a comment is refused with 400. That asymmetry is deliberate: approving says “this is what we agreed”, rejecting says “not this”, and only the second one needs to explain itself to the person who asked.

​
Its states

A failed attempt returns the request to approved and it is tried again, up to three attempts in all.

​
The guard that makes an old approval safe

A request records the target cluster’s UID when it is raised, and the UID is checked again at execution. If they differ, the deletion is marked stale and nothing is deleted. That is not a corner case: a request is valid for 24 hours, and a cluster can be destroyed and recreated under the same name within that window. Name and namespace would still match, and approving would delete the new cluster while everyone believed they were retiring the old one. If the cluster is gone entirely by the time approval lands, the request settles as completed — the intent was satisfied, just not by this call.
/iam/approvals lists what you may see. A cluster’s own page shows its active request, so you do not have to go looking to find out why a delete has not happened.

​
Permissions

Both are cluster-scoped, so approval authority can be granted for one namespace’s clusters and not another’s. The managed policies that carry them are K8sGateDeleteApprover and K8sGateClusterDeleteBypass — see Authentication & IAM.

​
What commonly goes wrong

Authentication & IAM

The managed policies that carry approval and bypass.

Delegate to a team

Handing out these grants deliberately, and what each one costs.

Slack notifications

Approving from a channel, and how the button click gets back.

Audit log

The record of who decided what, alongside every other mutation.