mirror of
https://github.com/cozystack/cozystack.git
synced 2026-11-09 05:25:14 +09:00
Aleksei Sviridkin
8e48cfc8fd
Two things this change got wrong about its own behaviour. tls.disableNonTLSListeners was silently discarded whenever TLS resolved to off, because the value was folded into the TLS condition before anything read it. Asking to close the plaintext listeners with TLS off leaves nothing listening, and the operator rejects the combination itself, returning "TLS must be enabled if disableNonTLSListeners is set to true" and setting ReconcileSuccess=False. Swallowing it in the chart was worse than what the operator does: the operator at least records a TLSError event, while a dropped flag rendered a healthy-looking cluster with every plaintext listener open and no trace of the request. The likeliest way in is an operator hardening an internal broker who sets only the flag, since tls.enabled follows external and so resolves to false there. Fail with a message naming tls.enabled instead. The README also claimed messaging clients are unaffected by enabling TLS. That holds only for a client with a hardcoded port. <release>-default-user is the Service Binding object the chart grants to the tenant, and the operator rewrites its port key from 5672 to 5671 as soon as spec.tls.secretName is set — gated on TLS alone, not on whether the plaintext listener stayed open — along with the per-plugin port keys. A binding-driven client, which is the documented way to consume it, follows that change and must speak TLS from then on, without being able to verify the certificate until the trust anchor is obtainable. Say so. Also record that the connection-uri annotation fans out: the operator's annotation filter strips only kubernetes.io and k8s.io keys, so it lands on every child object including the Secret the tenant reads. Assisted-by: LLM Signed-off-by: Aleksei Sviridkin <f@lex.la>