Broker TLS: add transport encryption to the operator-managed NATS broker (auth is already default)

Corrected 2026-08-17. The original text of this issue was wrong on two counts and is replaced below. Broker token authentication is already enabled by default, and the change this issue asks for is not a Helm chart change. Retaining the issue for the TLS half, correctly scoped.

What is already true (was previously misstated here)

Broker authentication is already on by default, with no user effort.

BrokerReconciler.reconcileBroker calls ensureAuthSecret unconditionally on every reconcile (controllers/broker_controller.go). That creates the meshery-nats-auth Secret with a freshly generated token before the NATS StatefulSet starts, and is a no-op once it exists so the token stays stable rather than rotating and dropping client connections. MeshSyncReconciler.ensureBrokerTokenSecret then republishes that token into MeshSync's namespace and delivers it via secretKeyRef, including when the broker lives in another namespace.

So there is no "unauthenticated by default" gap to close. Any documentation or assessment stating that the broker ships without authentication is out of date, including Meshery's own security self-assessment currently under CNCF TOC review (cncf/toc#2264).

What remains genuinely absent: TLS

There is no TLS anywhere in the broker path - not in the Broker CRD, not in the reconciler, not in the chart.

And this is not a Helm flag. The Helm chart does not deploy the broker. charts/meshery-broker renders a single Broker custom resource whose entire spec is version, service and size; the meshery-operator reconciles that into the NATS StatefulSet. Enabling TLS therefore requires, in order:

1. A BrokerSpec API change in meshery-operator to carry TLS configuration - a cross-repo CRD contract change, versioned across v1alpha1/v1alpha2.
2. Reconciler work to obtain, mount and rotate certificates, and to configure the NATS server to require TLS.
3. Client-side trust in Meshery Server and MeshSync.
4. Only then, Helm values to surface the option.

The design question that decides user impact

Certificate provenance determines whether this adds install friction at all:

• Operator-generated self-signed CA - zero user preparation. This mirrors exactly what ensureAuthSecret already does for the token, so the pattern is proven in this codebase. Strongly preferred.
• cert-manager - adds a hard dependency users must install first. Real friction for every deployment.
• User-supplied certificates - most friction; appropriate only as an override for operators who require their own PKI.

The requirement is that a default helm install must not become harder than it is today. Option one satisfies that; the others do not.

Acceptance criteria

• A default install gets broker TLS with no additional user steps and no new external dependency.
• Operators who require their own PKI can supply certificates explicitly.
• Certificate rotation does not drop broker connections, matching the care already taken with token stability.
• Meshery Server and MeshSync verify the broker's certificate rather than skipping verification.
• The production hardening guide and the security self-assessment are corrected to state that token auth is already default, and updated to describe the TLS posture accurately.