[GH-ISSUE #906] Feature Request: Allow TLS offloading for NATS #2503

New issue

Closed

opened 2026-03-14 04:17:01 +03:00 by kerem · 3 comments

kerem commented

2026-03-14 04:17:01 +03:00

Owner

Originally created by @joeldeteves on GitHub (Dec 28, 2021).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/906

Is your feature request related to a problem? Please describe.
Currently, tactical-nats is configured to point to an internal certificate file:

{"tls": {"cert_file": "/opt/tactical/certs/fullchain.pem", "key_file": "/opt/tactical/certs/privkey.pem"}, "authorization": {"users": [{"user": "tacticalrmm", "password": "my-password"}]}, "max_payload": 67108864}

This works fine for localized use cases (traditional Linux server or docker-compose) but not so well for setups that do TLS termination on the proxy side e.g. clustered setups like Kubernetes.

Describe the solution you'd like
See https://docs.nats.io/running-a-nats-service/configuration/securing_nats/tls#tls-terminating-reverse-proxies - it would be nice to have a custom dialer that takes input via an environment variable in the container. This way, we can configure "TLS offloading" of sorts for NATS.

Describe alternatives you've considered
A workaround for Kubernetes is to do TLS passthrough on the ingress controller and dump the certificates into the existing environment variables in the container but this is more complex and it's not ideal.

Additional context
I have been trying for a few days to get TacticalRMM working in Kubernetes - I am about 90% there but I have hit a snag with NATS due to the certificate issue. A custom dialer would make it a lot easier to configure

Originally created by @joeldeteves on GitHub (Dec 28, 2021). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/906 **Is your feature request related to a problem? Please describe.** Currently, tactical-nats is configured to point to an internal certificate file: ``` {"tls": {"cert_file": "/opt/tactical/certs/fullchain.pem", "key_file": "/opt/tactical/certs/privkey.pem"}, "authorization": {"users": [{"user": "tacticalrmm", "password": "my-password"}]}, "max_payload": 67108864} ``` This works fine for localized use cases (traditional Linux server or docker-compose) but not so well for setups that do TLS termination on the proxy side e.g. clustered setups like Kubernetes. **Describe the solution you'd like** See https://docs.nats.io/running-a-nats-service/configuration/securing_nats/tls#tls-terminating-reverse-proxies - it would be nice to have a custom dialer that takes input via an environment variable in the container. This way, we can configure "TLS offloading" of sorts for NATS. **Describe alternatives you've considered** A workaround for Kubernetes is to do TLS passthrough on the ingress controller and dump the certificates into the existing environment variables in the container but this is more complex and it's not ideal. **Additional context** I have been trying for a few days to get TacticalRMM working in Kubernetes - I am about 90% there but I have hit a snag with NATS due to the certificate issue. A custom dialer would make it a lot easier to configure

kerem closed this issue

2026-03-14 04:17:06 +03:00

kerem commented

2026-03-14 04:17:12 +03:00

Author

Owner

@joeldeteves commented on GitHub (Dec 29, 2021):

Just wanted to add to this, since I found a workaround by mounting secret volumes in Kubernetes (to pass the certificate files into the containers), I discovered that tactical-nats container also uses a hard coded certificate path baked into the container image.

It would be nice to be able to specify the certificate path using an environment variable if the first option (TLS offload) is not feasible.

Currently I am working around it using an init container & sed commands - a hacky solution!

@joeldeteves commented on GitHub (Dec 29, 2021): Just wanted to add to this, since I found a workaround by mounting secret volumes in Kubernetes (to pass the certificate files into the containers), I discovered that tactical-nats container also uses a hard coded certificate path baked into the container image. It would be nice to be able to specify the certificate path using an environment variable if the first option (TLS offload) is not feasible. Currently I am working around it using an init container & sed commands - a hacky solution!

kerem commented

2026-03-14 04:17:17 +03:00

Author

Owner

@silversword411 commented on GitHub (Jan 2, 2022):

So that PR solves this? Can we close?

@silversword411 commented on GitHub (Jan 2, 2022): So that PR solves this? Can we close?

kerem commented

2026-03-14 04:17:22 +03:00

Author

Owner

@joeldeteves commented on GitHub (Jan 2, 2022):