-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
scoped signing keys can't be used for KV/OBJ buckets. #5681
Comments
authorization in NATS is only good for basic operations like pub/sub and req/reply. |
nobody wants to respond to this design problems? |
@chezgi We realize we want better abstractions for authZ, especially within the realm of JetStream. The server's primitives are low level and core based on subject permissions. I think that is correct. The question we are working on is not only what the higher level authZ abstractions may or may not look like, but where they are interpreted. |
thanks @derekcollison,
NATS already has an authZ system that works on topics, but the API is expanding into headers and body. Checking headers and body could be expensive.
The first solution offers a better design with minimal impact on the code |
Can we add a namespace concept for Jetstream, or introduce a new separator within topics that could be used for wildcards and user tags?
|
There are several things we are considering. But good to understand that the core server will always operate on subject based permissions. We can abstract ACLs that can be decomposed into core subject based permissions for sure. We will also deliver a core callout option for any subject, similar to auth callout but for any subject, that would allow JS requests to be filtered through an external entity which can allow, modify or reject the request itself.. |
The authZ callout looks promising, but what about case-sensitive tags? Topics are case-sensitive, but tags aren't. Can this be fixed |
What do you mean by tags in this context? |
Users can have tags which a scoped signing key can expand with the |
As @ripienaar explained,
|
Looping in @aricart here as well. |
the tag restriction that it must be an entire token in the subject makes a workaround impossible - not sure how not to break anyone using this by changing it to case-sensitive - perhaps JWT could change to be case-insensitive but case preserving on the value portions of tags only. This would allow simple tags like hello still be forced to "hello", be lowercased, but tags like "n:HelloWorld" would lowercase the name of the tag |
I think I would change the API on jwt to have additional |
Thanks @aricart, can you and @ripienaar come to a decision here. Seems like case sensitive is important for this use case for sure since we depend on subjects here. |
Working on the PRs... |
@chezgi I have released nsc v2.9.0 which enables the use case. Let me know of any issues in the nsc repo |
@chezgi I have retracted the |
Thanks @aricart, |
yes that will work. Realize that name/account-name are possibly really bad options if the account/user name has a space. |
You can also do |
Thanks @aricart |
Observed behavior
it seems that we can't use scoped signing keys for KV/OBJ buckets.
we have some inconsistencies in NATS design decisions.
user tags is only applied to a whole section of topic, not to subsections.
but in KV service APIs, bucket name is part of an topic section. like:
$JS.API.STREAM.INFO.KV_bucket1
therefore we cant set permissions based on bucket name.
for example i cant restrict
$JS.API.STREAM.INFO
service to my bucket based on tags on scoped signing key.the tag
robucket:bucket1
, doesn't match$JS.API.STREAM.INFO.KV_{{tag(robucket)}}
user tags is lower case, but topics are case sensitive. and bucket names always prefixed by uppercase
KV_
for example
robucket:KV_bucket1
will be converted torobucket:kv_bucket1
and cant be used for template in permissionstherefore we cant use tags at all for restriction on buckets.
when nats topics are case sensitive, why tags are designed to be lower case?
Expected behavior
expected that i can use scoped signing keys to allow/deny some groups of users to read/write access on KV/OBJ buckets.
how we can improve scoped signing keys to be usable for KV/OBJ buckets?
it seams that:
Server and client version
in latest nats-server
Host environment
No response
Steps to reproduce
No response
The text was updated successfully, but these errors were encountered: