feat(tls): an instance asks for its certificate as part of provisioning, and is not 'ready' without it by rbuergi · Pull Request #4457 · Systemorph/MeshWeaver

rbuergi · 2026-09-15T19:39:18Z

A provisioning run renders its values from the deployment record. The cert-manager issuer lived only as a hand-written annotation in checked-in overlays, so a record without it rendered an ingress naming a TLS secret that nothing issued — the controller then served the fallback: another instance's certificate. pearl.meshweaver.cloud served CN=memex.meshweaver.cloud for nine hours on 2026-09-15 with a healthy portal behind it, and its own Provision could not have fixed it either: step 15/18 died on

certificates.cert-manager.io "pearl-tls" is forbidden: User
"system:serviceaccount:memex-ops:hosting-operator" cannot get resource "certificates"

so TLS and all three verification steps never ran.

What changes

Layer	Change
Contract	`IngressSpec.ClusterIssuer`, defaulted to Let's Encrypt production. An instance declared with a host and a TLS secret asks for its certificate with no further call, and a record written before the field gets one too — an absent JSON member leaves the initializer standing. A hand-written annotation still wins; the literal `none` is the named opt-out. `WithIngress` takes it.
Chart	the portal ingress renders the issuer from that value, and refuses to render a `tlsSecret` with no issuer reaching it.
Operator	`hosting-tls` takes `--issuer`, waits for the Certificate to be Ready and the Secret to hold a key pair, and names which of the two failed. `hosting-verify` reads the served certificate back: a wrong certificate is reported as a wrong certificate, not as thirty failed attempts that read like a dead application.
RBAC	the operator may get/list/watch/create/update/patch `cert-manager.io` Certificates.

Why the grant was missing

check-rbac-coverage.sh reads kubectl <verb> <resource> with literal resources and says so plainly: it cannot see kubectl apply -f -. hosting-tls created its Certificate exactly that way, so the script reached main without its rule and nothing was red. It now reads the object back explicitly — which it needs anyway for the Ready condition — so the grant is covered by the check from here on.

Verification, run locally

check-chart-invariants.sh: 11 combinations, 4 refusal controls, all green — including two new fixtures (a public host issued by cert-manager, a pre-provisioned secret) and the new refusal control (a TLS secret with no issuer).
operator/test/run-tests.sh: 471 passed, 0 failed, including 7 new ones — the fallback-certificate shape, the no-certificate shape, the wildcard shape, and that only a correct certificate lets the failure blame the application.
check-rbac-coverage.sh: 36 kubectl calls, 15 grants, 0 missing.
Contract tests: 17/17, including the default and that it never overrides a decision.

Not in this PR

The renderer half (MeshWeaver.Plugins: put the record's issuer into the rendered ingress values, refuse a TLS step for a record that names none) is a separate PR and needs this contract field sealed first, the same shape as #4417/#1919/#4453.

Deploy note: the new ClusterRole rule reaches the cluster when Systemorph/Memex's helm-release lane next deploys memex — that lane re-applies the operator's ClusterRole from this chart. Until then hosting-tls stays Forbidden.

🤖 Generated with Claude Code

…ithout it A provisioning run renders its values from the deployment RECORD. The cert-manager issuer lived only as a hand-written annotation in checked-in overlays, so a record without it rendered an ingress naming a TLS secret that nothing issued — and the controller served the fallback certificate, another instance's. pearl.meshweaver.cloud was in that state for nine hours on 2026-09-15 with a healthy portal behind it, and its Provision could not have fixed it either: step 15/18 died on certificates.cert-manager.io "pearl-tls" is forbidden: User "system:serviceaccount:memex-ops:hosting-operator" cannot get certificates so TLS and all three verification steps never ran. - contract: IngressSpec.ClusterIssuer, DEFAULTED to letsencrypt-prod, so an instance declared with a host and a TLS secret asks for its certificate with no further call — and a record written before the field gets one too, because an absent JSON member leaves the initializer standing. A hand-written annotation still wins; 'none' is the named opt-out. WithIngress takes it. - chart: the portal ingress renders the issuer from that value, and REFUSES to render a tlsSecret with no issuer reaching it at all. - operator: hosting-tls takes --issuer, waits for the Certificate to be Ready AND the Secret to carry a key pair, and names which of the two failed; hosting-verify reads the served certificate back and tells a wrong certificate apart from a dead application. - rbac: the operator may get/create/patch cert-manager Certificates. The coverage check now sees that grant, because hosting-tls reads the object explicitly — a Certificate created through 'kubectl apply -f -' is invisible to it, which is how this reached main ungranted. Tests: 2 contract tests (the default, and that it never overrides a decision), 7 operator tests incl. the fallback-certificate and wildcard shapes, 2 chart render fixtures and 1 chart refusal control. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

github-actions · 2026-09-15T19:44:51Z