Closed ChunyiLyu closed 1 year 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.
Closing stale issue due to further inactivity.
Reasonable feature. Shouldn't be closed because of staleness
@ChunyiLyu is there eny ETA of this enhancement?
@ChunyiLyu I am willing to work on. This is the only blocker for us using this operator
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.
Feature is not released just yet. Will close after that.
@ChunyiLyu thx for your work <3
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!
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.