Semantic Permissions

[ripienaar]

Proposed change

We should move to a model where the permissions for consuming from a stream in another account isn’t about listing n permissions but rather just expression a permission like stream_consumer(STREAM) in an ACL and the ACL will do the right thing.

This way as JetStream evolves and more subjects are added or changed the implications on ACLs are hidden from the user. It’s also just much easier.

This can take a number of forms:

• @bruth have made a proposal in this space ADR-32: Logical permissions nats-architecture-and-design#145 to expand the server
• We could turns this into an enhance-client behaviour by allowing each ACL to have a tag or metadata, this way user land tooling can add/remove ACLs and know what are the related set.

The server-side approach is preferable as this would make it much safer for us to develop future features. Today we often run into the scenario of adding a new API is hard because many users have locked down permissions and we do not control those. However if users locked their servers down using this kind of permission where the server expands it to ACLs we could expand to additional ACLs over time.

Use case

Enhance the ability for users to secure their systems without having to be experts on the jetstream implementation details

Contribution

No response

[MauriceVanVeen]

Have implemented a demo of this feature, it was surprisingly simple to add to all components involved. Expanding one semantic permission in a JWT into multiple allow/deny pub/sub permissions on the server.

$ nats auth user add semantic_user semantic_account --semantic-allow="js-manage-stream(benchstream)" --defaults --sub-allow '_INBOX.>' --pub-allow benchsubject --pub-allow '$JS.API.STREAM.NAMES'
...
Permissions:
  Semantic:
                Allow: js-manage-stream(benchstream)
  Publish:
                Allow: $JS.API.STREAM.NAMES
                       benchsubject
  Subscribe:
                Allow: _INBOX.>

Here the semantic permission of js-manage-stream(benchstream) expands into:

$JS.API.STREAM.INFO.<name>
$JS.API.STREAM.CREATE.<name>
$JS.API.STREAM.UPDATE.<name>
$JS.API.STREAM.DELETE.<name>
$JS.API.STREAM.PURGE.<name>

This simplifies creating credentials for a user that can only do nats bench commands for benchstream and benchsubject.

This is the generated JWT if you want to inspect it:

eyJ0eXAiOiJKV1QiLCJhbGciOiJlZDI1NTE5LW5rZXkifQ.eyJqdGkiOiJFNjdYVzNZSDdFVFBMUlpaV0g2WDQyVklKWTZHNDU2VDIzS1A1TllPS1ZIQlk1SlZNNlBRIiwiaWF0IjoxNzUyMDUyNTAwLCJpc3MiOiJBRE1YU1NQSlFQTFNSVlpJQjJGNU1PRVZFNzRMVDc2RlFPVFRUTjRPR0NMV1ZQSFNZNEdBTERQRSIsIm5hbWUiOiJzZW1hbnRpY191c2VyIiwic3ViIjoiVUJTT0NOTk1TM0hXR1lHWFdEM1A2NTIyQlkyVlU0RlhURlNUUk5TNk9aV0g0MlRMWDJHQ1U2UVIiLCJuYXRzIjp7InNlbWFudGljIjp7ImFsbG93IjpbImpzLW1hbmFnZS1zdHJlYW0oYmVuY2hzdHJlYW0pIl19LCJwdWIiOnsiYWxsb3ciOlsiJEpTLkFQSS5TVFJFQU0uTkFNRVMiLCJiZW5jaHN1YmplY3QiXX0sInN1YiI6eyJhbGxvdyI6WyJfSU5CT1guXHUwMDNlIl19LCJzdWJzIjotMSwiZGF0YSI6LTEsInBheWxvYWQiOjEwNDg1NzYsInR5cGUiOiJ1c2VyIiwidmVyc2lvbiI6Mn19.XV4ZRssgFQ98TV4HRmw0S5ALOQyiVr6yxy-3CZcKHxEPLfEH07aKvlwcRaBbTrjP8P8n4LVUGvFJxih9Xqc7DQ

Branches containing the code used for the demo:

• nats-io/jwt
• synadia-io/jwt-auth-builder.go
• nats-io/natscli
• nats-io/nats-server

Although not part of the current defined 2.12 milestone.
We could quite easily introduce this with a couple more of these permissions for consumers and stream get requests in 2.12, and then gather feedback to see what to do further?

I would recommend to then start with broad permissions first: allow management of a whole stream (or all streams with *), allow management of a whole consumer, and separate permissions for only consuming messages and getting messages directly from the stream.

[n-hass]

@MauriceVanVeen I'd be very excited for this feature as it would greatly simplify JS and KV management in production.

With the approach taken in your demo, it would be nice if you could use private inboxes. Could that potentially be defined as just an additional claim in the semantic object?

[MauriceVanVeen]

With the approach taken in your demo, it would be nice if you could use private inboxes. Could that potentially be defined as just an additional claim in the semantic object?

It would depend on how the design would end up, but something like private inboxes should be included for sure.