Skip to content

Emit path-based NATS address for Gateway installs#1287

Merged
ArnobKumarSaha merged 1 commit into
masterfrom
arnob-nats-gw
Jul 1, 2026
Merged

Emit path-based NATS address for Gateway installs#1287
ArnobKumarSaha merged 1 commit into
masterfrom
arnob-nats-gw

Conversation

@ArnobKumarSaha

Copy link
Copy Markdown
Member

The platform config (charts/ace/templates/platform/config.yaml) gated the path-based NATS endpoints behind ingress-nginx being enabled:

{{- if (and (index .Values "ingress-nginx" "enabled") (and .Values.nats.enabled (not .Values.nats.nats.externalAccess))) }}
EXTERNAL_ADDR  = nats://{{ .Values.global.platform.host }}:4222
WEBSOCKET_ADDR = wss://{{ .Values.global.platform.host }}/nats
{{- else }}
EXTERNAL_ADDR  = nats://nats.{{ .Values.global.platform.host }}:4222
WEBSOCKET_ADDR = wss://nats.{{ .Values.global.platform.host }}
{{- end }}

Gateway-based installs (ingress-nginx.enabled=false, gateway.enabled=true) fall into the else branch, which emits the subdomain form wss://nats.<host>.

Problem

When global.platform.host is an IP (self-hosted, DNS-less), the else branch yields wss://nats.<ip> (e.g. wss://nats.10.2.0.63), which:

  • is unresolvable — you cannot have a subdomain of an IP;
  • is not in the gateway cert SANs (ace-nats.ace.svc…, IP:<ip>).

So the audit / site-info NATS client (via b3 NATS.ExternalAddresses()kube-ui-server extended API) gets wss://nats.<ip> back and can never connect:

failed to connect to event receiver  error="dial tcp: lookup nats.10.2.0.63: no such host"

The Gateway already provisions the matching route — an HTTPRoute with PathPrefix: /nats<release>-nats:443 — i.e. exactly the path-based endpoint the if branch emits.

Fix

Take the path-based branch when either ingress-nginx or gateway is enabled. Gateway+IP installs then render wss://<host>/nats, which resolves (literal IP), TLS-validates (IP in cert SAN), and routes (existing /nats HTTPRoute).

The platform config gated the path-based NATS endpoints
(EXTERNAL_ADDR nats://<host>:4222, WEBSOCKET_ADDR wss://<host>/nats)
behind ingress-nginx being enabled. Gateway-based installs fell into
the else branch, which emits the subdomain form wss://nats.<host>.

For deployments where global.platform.host is an IP (self-hosted,
DNS-less), wss://nats.<ip> is unresolvable and not covered by the
gateway cert SANs, so the audit/site-info NATS client can never
connect. The Gateway already provisions an HTTPRoute matching
PathPrefix /nats -> <release>-nats:443, i.e. the path-based endpoint.

Take the path-based branch when either ingress-nginx or the gateway
is enabled.

Signed-off-by: Arnob Kumar Saha <arnob@appscode.com>
@ArnobKumarSaha ArnobKumarSaha merged commit 1c973b1 into master Jul 1, 2026
8 checks passed
@ArnobKumarSaha ArnobKumarSaha deleted the arnob-nats-gw branch July 1, 2026 03:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants