Azure Service Bus最小权限配置：多应用分队列权限管控问询

Hey there! Let's break down how to handle this scenario where multiple apps share an Azure Service Bus namespace but only need access to specific subsets of queues.

First, let's recap the pain points with the two default options you mentioned:

• Namespace-level Shared Access Keys (SAK)：Grants access to all queues in the namespace, which is way too broad for your use case (you don't want App 1 touching App 2's queues).
• Queue-level SAK：Works for single queues, but managing 40 separate keys (20 per app) would be a nightmare—rotating keys, distributing them to apps, and keeping track of which key maps to which queue gets messy fast.

The Better Approach: Azure RBAC (Role-Based Access Control) #

Azure RBAC is designed for exactly this kind of fine-grained permission management. It uses Azure AD identities (like service principals or managed identities) instead of static keys, making it more secure and easier to scale.

1. Use Built-in or Custom RBAC Roles

First, pick the right role for your apps:

• Built-in roles：If you just need basic send/receive access, you can combine Azure Service Bus Data Sender and Azure Service Bus Data Receiver roles. These can be applied directly at the queue level.
• Custom roles：If you need more specific permissions (e.g., only allow peeking messages, or exclude delete operations), create a custom role. Here's a simplified example of a custom role JSON that grants read/write access to queues:

  {
    "Name": "Service Bus Queue Reader-Writer",
    "Description": "Grants send and receive access to specific Service Bus queues",
    "Actions": [
      "Microsoft.ServiceBus/namespaces/queues/send/action",
      "Microsoft.ServiceBus/namespaces/queues/receive/action",
      "Microsoft.ServiceBus/namespaces/queues/peek/action"
    ],
    "NotActions": [],
    "AssignableScopes": [
      "/subscriptions/your-subscription-id/resourceGroups/your-resource-group"
    ]
  }
  

2. Assign Roles to Apps for Specific Queues

Once you have your role, assign it to your app's identity (service principal or managed identity) at the queue level:

• Manual assignment：For each queue that belongs to App 1, go to the queue's Access control (IAM) page in the Azure Portal, add a role assignment, select your role, and pick the app's identity.
• Batch assignment (CLI/PowerShell)：If your queues follow a naming pattern (e.g., app1-queue-01 to app1-queue-20), use Azure CLI to automate this. Example:

  # Set your variables
  SUB_ID="your-subscription-id"
  RG_NAME="your-resource-group"
  NS_NAME="your-servicebus-namespace"
  APP_SP_ID="app1-service-principal-id"
  ROLE_NAME="Service Bus Queue Reader-Writer"
  
  # Batch assign role to all App 1 queues
  for QUEUE in $(az servicebus queue list --resource-group $RG_NAME --namespace-name $NS_NAME --query "[?starts_with(name, 'app1-')].name" -o tsv); do
    az role assignment create \
      --assignee $APP_SP_ID \
      --role "$ROLE_NAME" \
      --scope "/subscriptions/$SUB_ID/resourceGroups/$RG_NAME/providers/Microsoft.ServiceBus/namespaces/$NS_NAME/queues/$QUEUE"
  done
  

3. Why RBAC is Better Than SAK

• Security: Uses Azure AD identities instead of static keys—you can revoke access instantly, use managed identities (no keys to manage at all), and enforce MFA for service principals if needed.
• Scalability: Adding new queues or apps is straightforward—just update the batch script or assign the role to the new queue.
• Auditability: All access is logged in Azure Monitor, so you can track who accessed which queue and when.

If You Must Use SAK (Not Recommended) #

If RBAC isn't an option for your setup, you can create queue-level SAKs for each of the 20 queues per app. For each queue:

1. Go to the queue's Shared access policies page in the Azure Portal.
2. Create a new policy with Send and Listen permissions.
3. Collect the primary/secondary keys and distribute them to the corresponding app.

Just keep in mind this requires manual key rotation and management, which gets tedious with 40 queues total.

内容的提问来源于stack exchange，提问作者Trondh