Freeze the Operation's Shape

"You froze which machines. Now freeze what the operation is — so a Low can't grow into a High while your back is turned."

Two things get frozen, not one

The durable-operations track froze which machines an operation targets. This one freezes what the operation is: its kind and its risk class. Both have to hold still from the moment of approval to the moment of execution, because approval is consent to a specific action against a specific set — change either half afterward and the consent no longer means what it said.

Kind and risk are domain-bound

A kind isn't a free-form label you can pick to taste; it's bound to a domain with a fixed risk class. restart_service is Medium; migrate_control_plane is High. You can't quietly relabel a High-risk action as a Low one to skip its ceremony, because the (kind → risk) mapping is defined once, in the domain, not chosen per request.

Re-validated at every boundary

The (kind, risk) pair is checked at three boundaries: when the operation is defined, when a delegate claims it, and when it starts. A delegate can't claim restart_service and quietly start doing purge_host_data; a start whose kind doesn't match the approved one is refused. Approval sticks to a specific action, not a loose category it could later drift within.

Fail closed, in every mode

And the response to any mismatch is the same everywhere: refuse. A kind-or-risk mismatch at any boundary fails the operation closed, in every mutation mode, whether production is locked down or wide open. The default on ambiguity is stop, never proceed — because the one time you let an unclear operation through is the time it turns out to have been the dangerous one.

Freeze the verb, not just the target. An approval that only pins which machines, but lets the action itself shift, approved a sentence with the most important word left blank.

Code

The (kind, risk) pair is re-checked at every boundary·python

# Kind -> risk is defined ONCE, in the domain -- not chosen per request.
DOMAIN = {
    "restart_service":        "medium",
    "apply_update":           "high",
    "migrate_control_plane":  "high",
    "purge_host_data":        "high",
}

def guard(op, expected_kind):
    # checked at define, at claim, and at start -- same check, three times.
    if op.kind != expected_kind:            fail_closed("kind changed")
    if op.risk != DOMAIN[op.kind]:          fail_closed("risk mismatch")
    if op.kind not in op.approved_kinds:    fail_closed("not what was approved")

# A delegate can't claim 'restart_service' and start doing 'purge_host_data'.
# Any mismatch, in ANY mutation mode, refuses -- the default is stop.

Exercise

Design an approval that pins both the target and the action. Write what you'd re-check at three moments — when the operation is defined, when someone claims it, and when it starts — and decide what happens on a mismatch. Then describe the 'wrapper' attack your three checks are designed to stop.

Hint

The wrapper attack is: approve something harmless, then change what it does while keeping the same id and approval. Your checks defeat it by binding the action to the domain's fixed risk and refusing any claim or start whose kind doesn't match what was signed off — with 'refuse' as the default, not 'allow.'

Two things get frozen, not one

Kind and risk are domain-bound

Re-validated at every boundary

Fail closed, in every mode

Code

External links

Exercise

Progress

Comments 0