Preventing Laser Access to Intermediate Messages

Question

After replacing the last azure deployment from the pre-production stage, I need to prohibit the role of an intermediate worker from receiving queue messages. I can do this by discovering that the environment is in the process of being staged or produced in code, but can someone tell me if there is any other way to prevent the middleware from accessing and processing the queue messages?

Thanks for the help! Mahesh

Answer 1

There is nothing in the platform that could do this. This is app / code. If the application has credentials (for example, account name and key) to access the queue, then it does what it encoded.

Answer 2

Your staging environment uses the primary storage key, and your production environment uses the secondary storage key. When you make a VIP exchange, you can restore the vault key that your staging medium uses, which will result in the user no longer having credentials to access the queue.

Please note that this leads to a synchronization problem. If you swap first and then change the storage keys, you run the risk that worker roles will collect messages between the two operations. If you change your keys first and then exchange, then there will be a second or two where your production service will no longer pull messages from the queue. It will depend on what your service does, whether this time problem suits you.

Answer 3

In fact, you can determine in which deployment slot the current instance is located. I explained in detail how to do this: fooobar.com/questions/596012 / ...

It really is not as simple as it should be, but it is definitely possible.

Answer 4

If this is a matter of protecting the DEV / TEST environment from your PRODUCT environment, you might want to consider separate Azure subscriptions (one for each environment). This template and practice guide outlines the benefits of this approach.

http://msdn.microsoft.com/en-us/library/ff803371.aspx#sec29

Answer 5

The answer to the regenerating keys is good, but I ended up with this:

• Optional - stop the role of the working worker from listening to the queue by changing the corresponding configuration key, which tells it to ignore messages, and then reboots the virtual machine (either through the management portal or by killing the WaHostBootstrapper.exe file)

• Publish to a phased environment (this will begin to access the queue, which in our case is wonderful)

• Step-by-step swap creation through Azure

• Publish again, this time in a new phased environment (old live)

You now have both worker and worker roles running the latest version and serving queues. This is good for us, as it gives us twice as many possibilities, and since the production works anyway, we can use it!

It is important that you use only the publishing phase as the publishing method (as expected) - to create a completely new environment for testing / quality assurance, which has its own account and message queues.