auth: add nkey auth

[drev74]

Hello

Currently, ajc supports only basic auth with creds and the context based auth. Both have limitations deploying on kubernetes.

• For context based auth, you can't easily create a custom context on kubernetes. Thus this method is unfavorable in production
• Basic auth works, but relies on user and password, which need to be specified in a helm chart. However, basic auth is NOT recommended in production and API uses an obsolete style:

nc, err := nats.Connect(cfg.Endpoint, nats.UserInfo(cfg.User, cfg.Pass), nats.UseOldRequestStyle())

How about implementing nkey based auth as per docs 🤔

[ripienaar]

nkey is a pretty bad choice for production use imo :)

But sure we can support that. Curious why making a context is hard? It’s just a json file and I believe, else we can fix that, you can set a path to the context json as argument.

It seems quite well suited to a configmap.

[drev74]

Curious why making a context is hard? It’s just a json file and I believe, else we can fix that, you can set a path to the context json as argument.

Following the code, I see you are the main tooling maintainer of everything-nats 😃 . Ok, let me complain you 😬

1. I install prod nats with helm from here. Here's is my config

---
container:
  image:
    tag: 2.11.2-alpine

natsBox:
  enabled: true
  contexts:
    default:
      nkey:
        secretName: nats
      
config:
  jetstream:
    enabled: true
    fileStore:
      pvc:
        enabled: true
        storageClassName: ssd-pool-default
        size: 1Gi

    memoryStore:
      enabled: true
      maxSize: 256Mi

    nats:
      secret:
        name: nats
        key: nats.nk

This is what I have after deployment:

> kubectl describe cm nats-config

====
nats.conf:
----
{
  "http_port": 8222,
  "jetstream": {
    "max_file_store": 1Gi,
    "max_memory_store": 256Mi,
    "store_dir": "/data"
  },
  "lame_duck_duration": "30s",
  "lame_duck_grace_period": "10s",
  "pid_file": "/var/run/nats/nats.pid",
  "port": 4222,
  "server_name": $SERVER_NAME
}

As you see, my nkey config and context wan't parsed. I can access a predefined context dev with nats context select dev.

2. I can access my prod cluster without any auth with: nats kv ls. So I assume that my new context with nkey auth was not created 🙄

[ripienaar]

Honestly I have no idea about the helm stuff :) I am maintainer and main author for the nats command and product owner for the server

[drev74]

I also found an article how to setup nats auth with the nsc tool here.

I did that locally, generated a new nats.conf as below:

// Operator "drev"
operator: eyJ0eXAiOiJKV1QiLCJhbGciOiJlZDI1NTE5LW5rZXkifQ.eyJqdGkiOiJOQUZJQzZUTUpUTEI2TU1WWDNVNlJLUEs3V0dZMlVMU1FURE9IWkhNQUVIRkdHQ1E0TDdRIiwiaWF0IjoxNzQ1ODQ5NjkyLCJpc3MiOiJ>

system_account: ACDZA6RXMFBLZJWAGQ7MVZIGUZTDATLLN7GJMYYZZU5KSUPKYCOJ7LUP

resolver: MEMORY

resolver_preload: {
  // Account "SYS"
  ACDZA6RXMFBLZJWAGQ7MVZIGUZTDATLLN7GJMYYZZU5KSUPKYCOJ7LUP: eyJ0eXAiOiJKV1QiLCJhbGciOiJlZDI1NTE5LW5rZXkifQ.eyJqdGkiOiJTSVlDRFFVWDRVTlk0NkJBV1A0TEZUU0JEMzNWRjdSVlpURFE1NUZVQ>

  // Account "drev"
  ACO6YXTU2HFTXMVEVKGABE4FRQ4IXHJEF2DPXRL4YPZPGJS365K4AVFQ: eyJ0eXAiOiJKV1QiLCJhbGciOiJlZDI1NTE5LW5rZXkifQ.eyJqdGkiOiJaWU8yWjZMUE9JSDM0VkRIRzVQU0VaUE9JR0ZNSFdFWFIyVlI1NkZRU>

}

But again, it's quite different from the original nats config for kubernetes provided before, so I'm not sure how to generate a full and working nats config with any working auth 🙄

[drev74]

Honestly I have no idea about the helm stuff

Probably, auth stuff needs to be separated from the config map in Kubernetes. You don't wanna save auth tokens and passwords in config map. Secrets need to be stored in Vault or other secrets manager

[drev74]

We can copy auth approach from ArgoCD. They offer to deploy server, support user secrets as kubernetes resources and offer cli tool to update passwords:

- Secure login: `argocd login example.com:443 --grpc-web --username admin`
- list all accounts: `argocd account list`
- update password: `argocd account update-password --account foo`

[ripienaar]

Indeed the nats context that ajc needs doesn't need to go anywhere near the server - its a different thing.

For auth if you follow the nsc or nats auth approach (https://github.com/nats-io/natscli/blob/main/AUTH.md) your server needs very little and you store the auth data elsewhere.

This is the general best model for prod use though