coulomb/the-custodian
4
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions
the-custodian/docs/kubernetes-change-gate-decision.md
codex e3d0d13253 Record the Kubernetes change gate in Mode of Authority terms; drop bare 'operator'. 
Option C: the gate on ADMINISTER @ realm:kubernetes is tiered by ADR-0006
readiness state. Below production-approved, activation=APPROVED by founder
plan approval; at production-approved, CONSTRUCT via ArgoCD for
external-audited evidence, direct apply only as activation=BREAK_GLASS.
rapp-policy-nexus gets a dated transition to 2026-12-21.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-21 14:07:30 +02:00

4.5 KiB
Raw Blame History

Kubernetes change gate: tiered by readiness state

Decided by: Bernd Worsch (founder), exercising GOVERN @ estate. Date: 2026-09-21. Recorded by: the-custodian.

Vocabulary: SecurityCanon Mode of Authority v0.2.0 (security-canon/infospace/vocabulary/mode-of-authority/), which is still a draft. Where that vocabulary changes, this record follows it.

This record answers gate-house's open question: which engine, if any, should own ops-mason's contact with the Kubernetes API.

The question, stated in the canon's terms

Applying manifests to a running cluster is ADMINISTER @ realm:kubernetes/railiance01. Changing the manifests is CONSTRUCT @ <manifest repository>. A GitOps controller separates the two: CONSTRUCT produces the definition, and the controller reconciles the cluster to it.

The question is what gates ADMINISTER @ realm:kubernetes, and whether that gate differs between experimental and production workloads.

Decision

  1. No engine owns the contact. The gate is a quality gate on a change, not an authorization decision. railiance-master ADR-0006 already keeps readiness and permission on separate axes: production-approved "is not an authorization decision". So no PDP belongs in this path. The Kubernetes API stays a Tooling contact, owned by rail-kubernetes.

  2. The gate is tiered by ADR-0006 readiness_state, not by Environment. railiance01 is a single cluster, and every workload on it shares one Environment. The canon's Environment dimension therefore cannot separate experimental from production here. The readiness state can.

    Readiness state of the target Path for a change Activation
    declared, installed, verified Direct ADMINISTER @ realm:kubernetes by ops-mason APPROVED: founder approval of the construction plan
    production-approved CONSTRUCT @ manifest repository, reconciled by ArgoCD (railiance-platform) APPROVED for the change; the merge is the gate
    production-approved, emergency Direct ADMINISTER BREAK_GLASS, recorded, reconciled back into the repository afterwards

    Platform objects that carry no readiness state default to the production tier.

  3. Why production goes through git: the EvidenceBoundary dimension. A direct apply is target-audited: the only evidence of the change is held by the realm being changed. A change through the manifest repository adds external-audited evidence, which survives the actor and the realm. For production that is the property that matters, and it is a statement about evidence, not about trust in ops-mason.

Transition for rapp-policy-nexus

rapp-policy-nexus is production-approved (reef-railiance bindings/rapps.yaml), but ArgoCD does not manage it. Its railiance-apps-root applications are external-secrets, issue-core, openbao-secretstore and target-revenue. So the production path does not yet exist for the one workload that needs it.

  • Until 2026-12-21: changes to policy-nexus keep activation=APPROVED by founder plan approval. Each change additionally records that its target is production-tier, so the transition is visible and does not look like conformance.
  • By 2026-12-21: policy-nexus is onboarded to ArgoCD. From then on, the production row of the table applies to it.

2026-12-21 is the same review date as the ops-mason plan-approval gate, so both come up together.

Scope of ops-mason's contact, as found

ops-mason's executor is narrower than a generic kubectl apply:

  • it confines each plan to one expected namespace;
  • it refuses the Pod and Secret kinds;
  • it rejects any manifest carrying data or stringData.

This decision relies on those limits. Widening them is a new decision.

Not verified here

Whether ArgoCD is currently syncing on railiance01 could not be checked from the workstation, whose kube context is not the production cluster. The production row assumes ArgoCD works as its repository declares.

Owners

  • gate-house: the open question is answered. No engine owns the contact, and the gate is quality, not authorization.
  • ops-mason: phase 4 checks the target's readiness state and refuses a direct apply to a production-tier target, except under BREAK_GLASS or the policy-nexus transition.
  • railiance-platform: the ArgoCD lane is the production path, and policy-nexus onboarding is due by 2026-12-21.
  • railiance-master: ADR-0006 gains a deploy-path consequence for production-approved.
  • rapp-policy-nexus: the transition and its date.