I'm building a queue messaging system in Azure and what I'm trying to do is an outbound message queue container in Azure Storage Queue that allows my desktop Windows Services to get the latest messages from that queue. The problem I'm facing is that I want to have multiple queues per tenant (each Windows service serves one client) in one storage account. As far as I see, there is no way to restrict the connection string access to each queue. On the other hand, it is not practical for me to create one storage account per tenant. What is the best way to restrict client access to one specific queue with the current security methods available in Azure? I was thinking about using Service Bus Queues, but even that doesn't solve the connection string issue I have in the client application.
I think service bus queues is your answer; they allow a multi-subscriber model with "subjects" and various filters etc.
Storage queues are very simplistic and are not the right answer for this particular scenario.
Sorry, on my mobile so haven't got all the relevant docs to hand.
One option is to use AAD identities and Storage's AAD authentication support (which is currently in public preview).
You would need a Service Principal in Azure AD for each tenant for this,
and add the principal to the Storage Queue Data Reader or Storage Queue Data Contributor role on their respective queue.
You can then use the principal's credentials to get an access token that is tenant-specific.
Documentation:
https://azure.microsoft.com/en-us/blog/announcing-the-preview-of-aad-authentication-for-storage/
https://joonasw.net/view/azure-ad-authentication-with-azure-storage-and-managed-service-identity
Related
We have a microservice which forwards Salesforce Event Bus Channels to Azure Service Bus Topics.
We want to give Microsoft Dynamics access to some -- but not all -- of the Topics.
While I could create a listen policy for each Topic and then give the Dynamics 365 developers a dozen connection strings, this seems less than ideal.
Is there a way to create a policy and connection string which would allow listening to an arbitrary collection of Topics on the Azure Service Bus without granting access to all of the Topics on the same bus?
AFAIK you can't have a SAS for multiple entities, but you can leverage Azure AD based authentication/authorization instead by giving your app registration access to multiple entities.
Another option would be to chain entities with auto forwarding by creating a single final queue where are messages are forwarded from the topics that you need, and dynamics would have access only to the final queue. When you need to add/remove topics, it would only have to be done in Service Bus and dynamics would just continute to listen on the same final queue.
I am using a service bus queue that uses sessions, and currently, something is receiving and deleting my messages.
The problem is that I don't know what is requesting the service bus queue.
Is there someway for me to see what/who is requesting my Azure service bus queue?
let me know if you need more information.
If you have shared the SAS token and now you don't want to do that. I recommand that you could regenerate the policy key from Azure portal.
I have a security question related to Azure that I could really do with some guidance on the art of what is possible.
I would like to know if it is possible to restrict what services can be called (i.e what storage account endpoints can be used to write data to) from PaaS services such as service fabric or web apps (ASE). i.e. if I have a web app that writes to storage and someone maliciously altered the code to write to a third party storage account on Azure; is this something I could mitigate in advance by saying this application (i.e. this web app or this SF cluster) can only talk to a particular set of storage accounts or a particular database. So that even if the code was changed to talk to another storage account, it wouldnt be able to. I.e can I explicitly define as part of an environment what storage items an application can talk to; Is this something that is possible?
Azure Storage Accounts have Access Keys and Shared Access Keys that are used to authenticate REST calls to read / write data to them. Your app will be able to perform read / write operations against the Azure Storage Account that it has an access key and connection string for that it uses to connect to it with.
It's not possible to set any kind of firewall rule on an Azure App Service app to prevent it from communicating with certain internet or Azure endpoints. You can set NSG firewall rules with App Service Environment, but you still can only either open or close access; not restrict on certain DNS names or IP Addresses.
Perhaps you should look for a mitigation to this threat in the way applications are deployed, connection strings are managed and code is deployed:
Use Azure Role Based Access control to limit access to the resource in Azure, so unauthorized persons cannot modify deployments
Use a secure way of managing your source code. Remember it is not on the PaaS service, because that only holds the binaries.
Use SAS tokens for application access to storage accounts, not the full access keys. For example, a SAS key could be given write access, not read or list access to a storage account.
If, as a developer, you don't trust the person managing the application deployment, you could even consider signing your application parameters/connection strings. That only protects against tampering though, not against extraction of the connection string.
How would you go about using Service Bus in a scenario where only client applications with unexpired subscriptions can receive messages from the service bus? Let's say you have a paid service where users can buy subscriptions to your messages for a period of time, so you want your service bus to send new messages only to a selected group of clients (clients with active subscriptions). It is much preferred if authorization for this is done on the server side and not on the client app. Looking at the service bus models (queues, topics, relays), none of them seem to fit this use case.
One way I was thinking to implement this was to change the SAS Key every day and get client applications to query the SAS key from a Web API. So only clients with valid subscriptions can refresh their SAS and receive from the service bus. I don't know if SAS could be changed through the API, though.
Is there any better support for this kind of scenario in Azure Service Bus, or can you think of a better way to implement it?
Is there currently a way to autoscale an Azure App Service plan by a "v2" storage account message queue? When I attempt to set up autoscaling based on a message queue, it is only showing my "classic" storage accounts. I would prefer to not destroy and recreate the storage account as classic just because of this.
Currently that supports classic storage accounts only. I would suggest you to provide feedback here: https://feedback.azure.com/forums/169385-web-apps-formerly-websites