search

nats-io / nsc

Tool for creating nkey/jwt based configurations
Apache License 2.0
98 stars 44 forks source link

prune local #659

Open tommyjcarpenter opened 1 month ago

tommyjcarpenter commented 1 month ago

What motivated this proposal?

There is already the opposite of this command, push --prune.

What is the proposed change?

I'd like a command nsc pull --prune-local that deletes any local accounts that are not in the remote server. Basically I want the reverse of push --prune.

Currently, I cannot see any easy way to do this: pull -A pulls from the remote server, but mixes with local accounts.

Who benefits from this change?

Users of a shared NATS server who may want to keep their local nsc in sync. If I sync my nsc, then an operator deletes a remote account, I'd like to (explicitly with --prune-local) be able to sync those changes.

What alternatives have you evaluated?

No response

aricart commented 2 days ago

Would you agree that the issue is more because there's no centralized repository for the JWT/key artifacts? We have started on a different project for building the configurations (this is being used by the nats cli) which has a API which can work of a KV in NATS, meaning that you could store the configurations in a centralized place, and keys etc are managed automatically.

aricart commented 2 days ago

https://github.com/synadia-io/jwt-auth-builder.go

tommyjcarpenter commented 1 day ago

I think so - If you mean that clients' nsc will no longer use a local, distributed repository, and instead connect to a centralized store (and no local store), then yes, that would also solve this issue :)

In fact, that's exactly what I want. What we built is an API around NATS auth that ties into our central auth, and currently that API wraps NSC for the actual part where it pushes accounts to the NATS server. Then, we use the NATS auth callout feature.

But, the reason I asked the above is, we have several pods; and I need to keep them in sync, so if an account is deleted via one API pod, I was looking for a way for the other API pods to "get" that update. I was thinking of a minute --prune operation or something to that effect.

However, if there is a replacement for nsc coming that I can replace nsc with (inside this API), that instead uses a remote central location, this solves both problems at once!

Do I have this right? If so, Is there an ETA for general readiness for that? Thanks much