Problem
On public kars-bridge at 3bc7ff58d8d2994e474be39fd2af201d750fc5c2, completed private enrollment binds the reviewed controller Pod template into the root retirement proof. A later image/environment/template change has no supported migration path preserving existing grants and qualification continuity.
Normal upgrade paths can still change Helm resources and add a rollout-restart annotation, then report Deployment availability. Availability is not proof that private continuity remains valid. Even an operational change such as correcting sandbox.nodeSelector changes the controller's sealed template.
The admitted-Pod recovery repair in #566 handles legitimate admission changes against an unchanged reviewed template. It does not solve root-template migration.
Required immediate boundary
Controller-changing upgrade/restart workflows should refuse before their first mutation when a private root is sealed or recovery is incomplete. They must report the unsupported transition explicitly, not clear metadata, delete/recreate grants, reset epochs, ignore template fields or report a healthy rollout as qualified.
Preserve normal unqualified/standalone installations and operations that do not change the protected root. Original-scope credential recovery must remain available.
Migration requirements
A supported migration needs an explicitly reviewed, restartable transaction understood by both the CLI and controller, not an exception in template comparison:
- Bind old and proposed immutable image/template identities, unchanged namespace/ServiceAccount/Deployment/profile identities, and a complete inventory of affiliated protected namespaces and grants, including retained scopes without a current grant.
- Preserve grant UIDs, non-activation spec and customer data. Temporarily quiesce captured writer authority while the old controller can remove its owned permissions; verify real role/guard withdrawal.
- Retire actual old consuming Pod UIDs, including terminating and newly observed old-template descendants. Replica count alone is insufficient.
- Bind exact Helm render/release identities before writes; perform cutover with controller replicas zero. Do not silently append an unreviewed restart or roll back an old qualification proof.
- Issue fresh epochs after retirement, qualify the exact replacement root against supported admission, then requalify and restore each captured grant through UID/resourceVersion-fenced progress.
- Persist bounded predecessor/target evidence and distinguish a lost successful response from an unexecuted operation. Resume after every phase without inventing witnesses or reopening writers early.
- Have core reject active grant use during an incomplete transition and verify the active proof against the actual live root template after publication.
A narrowly scoped first implementation may support root-only consumers and unchanged admission/RBAC/budget identity. Unsupported runtime, budget-TLS or policy migration must fail before writes, rather than enter a partially supported transition.
Acceptance
Cover positive upgrades, multiple and inactive grants, retained namespaces, wrong/replaced identities, complete inventory failures, delayed/terminating Pods, concurrent changes, every write/response crash boundary, partial Helm apply and publication, mutable/wrong images, unsupported scope, and controller-enforced fail-closed behavior.
Require real native Kubernetes/Helm execution and matching-source container qualification. A new state-machine document, fixtures alone, or a healthy Deployment is not acceptance.
This issue records a beta deployment blocker. It does not authorize customer-data resets, private-proof bypasses, or infrastructure/GPU changes.
Problem
On public
kars-bridgeat3bc7ff58d8d2994e474be39fd2af201d750fc5c2, completed private enrollment binds the reviewed controller Pod template into the root retirement proof. A later image/environment/template change has no supported migration path preserving existing grants and qualification continuity.Normal upgrade paths can still change Helm resources and add a rollout-restart annotation, then report Deployment availability. Availability is not proof that private continuity remains valid. Even an operational change such as correcting
sandbox.nodeSelectorchanges the controller's sealed template.The admitted-Pod recovery repair in #566 handles legitimate admission changes against an unchanged reviewed template. It does not solve root-template migration.
Required immediate boundary
Controller-changing upgrade/restart workflows should refuse before their first mutation when a private root is sealed or recovery is incomplete. They must report the unsupported transition explicitly, not clear metadata, delete/recreate grants, reset epochs, ignore template fields or report a healthy rollout as qualified.
Preserve normal unqualified/standalone installations and operations that do not change the protected root. Original-scope credential recovery must remain available.
Migration requirements
A supported migration needs an explicitly reviewed, restartable transaction understood by both the CLI and controller, not an exception in template comparison:
A narrowly scoped first implementation may support root-only consumers and unchanged admission/RBAC/budget identity. Unsupported runtime, budget-TLS or policy migration must fail before writes, rather than enter a partially supported transition.
Acceptance
Cover positive upgrades, multiple and inactive grants, retained namespaces, wrong/replaced identities, complete inventory failures, delayed/terminating Pods, concurrent changes, every write/response crash boundary, partial Helm apply and publication, mutable/wrong images, unsupported scope, and controller-enforced fail-closed behavior.
Require real native Kubernetes/Helm execution and matching-source container qualification. A new state-machine document, fixtures alone, or a healthy Deployment is not acceptance.
This issue records a beta deployment blocker. It does not authorize customer-data resets, private-proof bypasses, or infrastructure/GPU changes.