rabbitmq / messaging-topology-operator

RabbitMQ messaging topology operator
Mozilla Public License 2.0
126 stars 66 forks source link

Be able to create/update/delete topic permissions #191

Closed ChunyiLyu closed 1 year ago

ChunyiLyu commented 3 years ago
As a service operator running RabbitMQ on Kubernetes
I would like to declaratively configure topic permissions
So that I can enforce authorization for MQTT and STOMP applications

Describe the solution you'd like An API for topic permissions, similar to the API for permissions or policies

As with other similar APIs, the contract with the cluster-operator should be minimal, via the cluster-reference and consuming the default-user secret, which conforms to the Provisioned Service binding specification. The controller reconciling the Custom Resources should interact with the RabbitMQ cluster via the RabbitMQ HTTP API via the kubernetes service associated to the RabbitMQ cluster.

Additional context Topic authorisation targets protocols like STOMP and MQTT, which are structured around topics and use topic exchanges under the hood. RabbitMQ supports topic authorisation for topic exchanges. The routing key of a message published to a topic exchange is taken into account when publishing authorisation is enforced (e.g. in RabbitMQ default authorisation backend, the routing key is matched against a regular expression to decide whether the message can be routed downstream or not).

Topic authorisation is an additional layer on top of existing checks for publishers. Publishing a message to a topic-typed exchange will go through both the basic.publish and the routing key checks. The latter is never called if the former refuses access.

Topic authorisation can also be enforced for topic consumers. Note that it works differently for different protocols. The concept of topic authorisation only really makes sense for the topic-oriented protocols such as MQTT and STOMP. In AMQP 0-9-1, for example, consumers consume from queues and thus the standard resource permissions apply. In addition for AMQP 0-9-1, binding routing keys between an AMQP 0-9-1 topic exchange and a queue/exchange are checked against the topic permissions configured, if any.

github-actions[bot] commented 3 years ago

This issue has been marked as stale due to 60 days of inactivity. Stale issues will be closed after a further 30 days of inactivity; please remove the stale label in order to prevent this occurring.

github-actions[bot] commented 2 years ago

Closing stale issue due to further inactivity.

ChunyiLyu commented 2 years ago

Reasonable feature. Shouldn't be closed because of staleness

grafjo commented 2 years ago

@ChunyiLyu is there eny ETA of this enhancement?

AntonAleksandrov13 commented 2 years ago

@ChunyiLyu I am willing to work on. This is the only blocker for us using this operator

ChunyiLyu commented 2 years ago

Hi @grafjo @AntonAleksandrov13 👋 thanks for the feedback! I'm working on this now and our next release would likely be before October. Will let y'all know once we cut the next minor.

ChunyiLyu commented 1 year ago

Feature is not released just yet. Will close after that.

grafjo commented 1 year ago

@ChunyiLyu thx for your work <3

ChunyiLyu commented 1 year ago

Hi @grafjo @AntonAleksandrov13 👋 the latest topology operator 1.9.0 adds a new topicpermissions.rabbitmq.com CRD. You can update and check out examples here on how to use it 😀 Thank you!