Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[nats helm] Support config for gateway.gateways and leafnodes.remotes #772

Open
caleblloyd opened this issue Aug 2, 2023 · 3 comments
Open

Comments

@caleblloyd
Copy link
Collaborator

gateway.gateways and leafnodes.remotes are both lists that support a tls block

Also, a server might not need to be listening on the leafnodes port in order to have a leafnodes.remote block. The same may be true of a gateway. If this is the case, these should probably be keys under config such as config.leafnodeRemotes and config.gatewayRemotes so that the Leafnodes/Gateways Servers can be managed separately from Clients

@J11522
Copy link

J11522 commented Dec 18, 2023

Any updates on this?
We are currently running into trouble configuring the remotes for the leafnodes when it comes to the cluster credentials.
Having dedicated keys would greatly help, e.g. mounting the credentials file from a secret is (AFAIK) currently not possible.

Alternatively this could be solved using generic extraVolume/extraVolumeMounts pattern.
If you feel this is something that could be done, I can create a dedicated ticket and potentially provide input

@mccullough-ea
Copy link

mccullough-ea commented Apr 17, 2024

I had to hard code the ca_file path for our leafnodes for each of the remotes that offer certs signed by our private CA.

tls:
  ca_file: /etc/nats-ca-cert/ca.crt

I would love the remotes to be able to inherit the settings from tlsCA like all the other sections.

@tommyjcarpenter
Copy link

Adding my support for this. I raised an issue that was seemingly a duplicate before finding this.

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

No branches or pull requests

4 participants