Support for authenticated NATS clusters

[thomasrutger]

I am trying to deploy CFM on our cluster as it seems promising to help manage our EDC workloads. Our NATS cluster is secured with NKey authentication. I noticed NewNatsClient supports nats.Option, but none of the call sites seem to supply options, so the code always connects without auth. Is CFM currently assuming an unsecured JetStream setup, or is there a configuration path for NKey (or other) auth that I’m overlooking? If it is currently not supported, are there any plans to support this?

[paullatzelsperger]

yep, that is something we haven't gotten around to yet, but we are aware. It is definitely on our roadmap, but we don't have concrete timelines yet.

Would you be willing to contribute this? If so, could you outline a coarse implementation plan?

[thomasrutger]

Yes I would. After doing a bit of digging through the repo I currently see two paths:

• Introduce a helper such as natsclient.BuildOptionsFromConfig(cfg) that converts a config (struct) into []nats.Option. Any place that currently calls natsclient.NewNatsClient(url, bucket, opts...) can invoke this helper first and append the resulting options. This is the most straightforward option I´d say and does not change the signature of natsclient.NewNatsClient.
• More involved, but a bit more flexible: Add a natsclient.ClientConfig struct (URL, bucket, plus an AuthStrategy). The AuthStrategy interface would expose Options() ([]nats.Option, error), with one implementation per supported auth mechanism (user/pass, token, NKey/JWT, etc.). Each implementation returns the relevant options for that auth strategy. Assemblers/launchers convert their config to a ClientConfig (possibly using a helper inside natsclient), then call
  natsclient.NewNatsClient(cfg), which replaces the current implementation of natsclient.NewNatsClient. The AuthStrategy can be selected based on a setting.

[paullatzelsperger]

Personally, I'm partial to the second, more flexible approach. Additional auth methods are likely to be needed in the future. CFM is not yet in a maturity state where we have to worry about keeping method signatures stable.

I assigned you the issue.

[thomasrutger]

Personally, I'm partial to the second, more flexible approach. Additional auth methods are likely to be needed in the future. CFM is not yet in a maturity state where we have to worry about keeping method signatures stable.

I assigned you the issue.

I agree, this can also be extended later with e.g. TLS options. Thanks for assigning this, appreciate it! I’m a bit busy this week, but I’ll try to get a PR up soon.

[paullatzelsperger]

hey @thomasrutger are you still planning on working on this?