ADR-32: Logical permissions

[bruth]

No description provided.

[wallyqs]

Maybe also need to cover how this maps to the imports and export syntax while we are at it, sub represent either a stream or service.
Like being able to define that reading info about consumer and streams is ok from the other account but not ok to create, something like:

  exports: [{stream: "foo"}, { jetstream: { streams: [ { name: EVENTS, export: [stream-info, consumer-info] }]

[bruth]

Indeed. Fundamentally, these permissions can be thought of as functions that expand to one or more subjects js-stream-info(EVENTS) → $JS.API.STREAM.INFO.EVENTS. I thought about having these permissions able to be intermingled with standard subjects. If that is the case, the ambiguity of subject vs perm needs to be removed, so some kind of prefix character could help differentiate, such as @ or whatever.

Then you could have something like:

exports: [
  {service: "@js-stream-info(EVENTS)"},
]

The implicit pub/sub information would really only apply in the user permissions context.

[wallyqs]

this syntax is nice, I was thinking of granular permission like below but seems very verbose:

    permissions = {
      # Can publish to stream
      publish: { allow = ["a"] } 

      # Granual permissions for JetStream features
      jetstream: {
        streams { EVENTS = { allow: [ stream-info ], deny: [add-stream, delete-stream] } }
        kv { TEST = { allow: [ put, del], deny: [ destroy-kv ] }
        object-store { allow: [...] }
      }
    }
   }

[bruth]

I like the structure that your example provides which provides namespacing (as I am doing js- and kv-). A future state I considered was user-defined permissions which may break the structure. For example, if a new key called roles within an account is defined, you could declare new mappings off the primitive logical permissions the NATS server provides.

[aricart]

It should be possible to subset keys/object names on kv/object store - currently object store doesn't expose data chunks in a way that can be clamped.

[MauriceVanVeen]

Looks really cool! Decouples the configuration from the concrete subjects.

What I'm wondering, how would this work for consuming a stream/watching a KV?

I'm thinking that would be a combination of several permissions, for example:

js-create-ephemeral-consumer
js-consumer-next-msg
js-consumer-ack-reply
etc.

However, that would still require you to know the relationship between multiple permissions, as those need to be combined in order to: create an ephemeral consumer, start consuming from it, and maybe at some point delete the consumer, etc.

I like the syntax of @wallyqs as well, albeit a bit more verbose, it might be more concise with the addition of watching a stream for example:

    permissions = {
      jetstream: {
        streams { EVENTS = { allow: [ watch-ephemeral ] }}
      }
    }

With a short-hand like watch-ephemeral it might combine the ability to both create and delete an ephemeral consumer, as well as receive messages from it, handle heart beats/flow control, etc. This could make a leaf node scenario quite easy as well, just add a watch-ephemeral add a sourced stream on the leaf node and you're off.