We were going through the security of the AMQP setup for a multi-tenant environment. We were wondering whether we could have a good setup with a single AMQP user for the client service (but client-specific signatures). We'd have to allow clients configuring their queues that are bound to the default exchange, allow reading from there, and allow writing to keepalives and results.
The one hole we found is that we can't come up with a regexp that limits the configure option reasonably. AFAICT we will always allow any client to delete any queue from another client. This isn't too bad, except that the affected client won't notice that his queue went away and sits around not receiving check requests any longer until he gets restarted.
I saw that you removed the exclusive tag quite a while ago, but that seems to be specifically made for this use case. The pull request talked about race conditions. I wonder whether that issue is maybe gone now and using exclusive queues is feasible again?
In addition, or alternatively, it could be helpful just to obfuscate the queue names further, as they can't be enumerated by other clients and would have to be guessed. Starting time is quite easy to guess. Trying for all seconds in the last year are only 12 million variations. As AMQP is quite fast I assume we can guess at least 100-1000 variations per seconds, reducing the ability to delete a foreign queue to within less than a day -- I think we could do better.
We were going through the security of the AMQP setup for a multi-tenant environment. We were wondering whether we could have a good setup with a single AMQP user for the client service (but client-specific signatures). We'd have to allow clients configuring their queues that are bound to the default exchange, allow reading from there, and allow writing to keepalives and results.
The one hole we found is that we can't come up with a regexp that limits the configure option reasonably. AFAICT we will always allow any client to delete any queue from another client. This isn't too bad, except that the affected client won't notice that his queue went away and sits around not receiving check requests any longer until he gets restarted.
I saw that you removed the
exclusivetag quite a while ago, but that seems to be specifically made for this use case. The pull request talked about race conditions. I wonder whether that issue is maybe gone now and using exclusive queues is feasible again?In addition, or alternatively, it could be helpful just to obfuscate the queue names further, as they can't be enumerated by other clients and would have to be guessed. Starting time is quite easy to guess. Trying for all seconds in the last year are only 12 million variations. As AMQP is quite fast I assume we can guess at least 100-1000 variations per seconds, reducing the ability to delete a foreign queue to within less than a day -- I think we could do better.