RBAC in Azure: Control vs Data Plane Permissions

Introduction

I encourage you to read this post first to get the most out of the information provided here:

• RBAC in Azure: Roles, Scopes and Security Principals Explained

In the first post, we explored the fundamentals of Azure RBAC: security principals (who), roles (what), and scopes (where). With that foundation in place, we can now move into one of the most important distinctions in RBAC in Azure which is the difference between Control Plane and Data Plane operations.

We will define what the Azure Resource Manager (ARM) is and how it relates to the control plane, examine how RBAC roles map to each plane, and discuss why this separation exists. Finally, we’ll highlight best practices to ensure your access model remains secure and manageable.

Control Plane

The control plane (a.k.a. the management plane) in Azure refers to all the operations that manage resources themselves: creating, configuring, and deleting them. It’s the layer where we define how resources should exist and behave, rather than interacting with the data those resources contain. The key component which allows to process all control plane requests is Azure Resource Manager (ARM) and the history of all operations invoked against it can be found in the Activity Log.

Examples of the control plane roles:

• Owner
• Contributor
• Reader

Azure Resource Manager

ARM is the management gateway for Azure. Every request (requests are sent to management.azure.com) to create, update, or delete a resource flows through ARM, whether it comes from the Portal, CLI, PowerShell, or SDKs.

It does not matter whether you invoke given operation in the Azure Portal, using AZ CLI, PowerShell or various Azure services SDKs, all of them will be routed to the one and the same component – Azure Resource Manager.

The idea is simple: whenever you try to create, read, update or delete a specific resource in Azure then ARM first checks your identity, then the operation you want to perform and then it verifies if you have appropriate permissions to invoke that operation. You can think about it as a usual Authentication (who you are) + Authorization (are you allowed to invoke given operation) flow.

Resource provider

A resource provider in Azure is a service that supplies and manages specific types of resources. Each provider offers a set of operations that you can use through Azure Resource Manager. For example, Microsoft.ServiceBus is the resource provider for Service Bus, exposing operations to create, read, and manage queues, topics, and subscriptions.

Activity Log

The Activity Log records all control plane operations in Azure. It’s essentially the audit trail of who did what, when, and where at the management layer.

Activity Log captures events like resource creation, deletion, and configuration changes and some read operations, but not data‑plane actions such as querying a database or reading a message from a queue.

As you know from the previous post, there are four main scope levels in Azure: management groups, subscriptions, resource groups, and individual resources. Therefore, if you make a change at the individual resource level, it will also be reflected at the higher levels in that logical hierarchy.

Example: I regenerated a primary key in the Azure AI Search service which lives in the deployed-in-azure-ai-search resource group.

We can find the same events at the higher levels of the logical hierarchy. Below, you can see the Activity Log in the deployed‑in‑azure‑ai‑search resource group, where the Azure AI Search service is deployed.

Use cases:

• Security auditing: Track unauthorized or unexpected changes.
• Troubleshooting: Identify when and why a resource was modified.
• Compliance: Provide evidence of governance and operational oversight.

Data Plane

While the control plane governs management operations (creating, configuring, deleting resources), the data plane is all about interacting with the contents of those resources. This distinction is critical.

Having permission to manage a resource (control plane) does not automatically grant permission to access its data (data plane).

Data plane operations are not recorded in the Activity Log (which only tracks control plane actions).

Examples of the data plane roles:

• Key Vault Secrets User
• Storage Queue Data Message Sender
• Azure Service Bus Data Receiver

ℹ️Data‑plane roles aren’t always available in Azure. Some services use their own RBAC systems, so you’ll need to check the documentation for setup details. For example, Azure SQL Database doesn’t expose data‑plane roles and hence access must be managed directly at the service level. In these cases, you configure your security principal so the service recognizes it, then assign the right roles there.

RBAC Role definition

Now that we understand the control‑plane and data‑plane concepts, it’s the right time to analyze how an RBAC role definition looks.

Built-in roles

Let’s analyze the definition of the Azure Service Bus Data Receiver role.

1. Built‑in role: The definition indicates that this is a built‑in role provided by Azure.
2. Microsoft.Authorization is a resource provider responsible for storing role definitions.
3. assignableScopes defines at which scope (the where question) the role can be assigned. In this case / means the role can be assigned at all possible scopes.
4. actions and notActions define allowed operations and exclusions for control‑plane activities. These are management operations (like creating or reading metadata about queues or topics) that flow through Azure Resource Manager (ARM) and they are expressed using the Microsoft.ServiceBus resource provider.
   • * matches any resource type under Service Bus (queues, topics, subscriptions). Instead of listing each one individually, the * acts as a placeholder for “all.”
5. dataActions and notDataActions define allowed operations and exclusions for data‑plane activities. These are runtime operations (like receiving messages) that are enforced directly by the Service Bus service itself (these request DO NOT go through ARM!), though the permissions are still described using the same Microsoft.ServiceBus namespace for consistency.

ℹ️ Based on the Azure Service Bus Data Receiver role, you may notice that control‑plane permissions are sometimes mixed with data‑plane permissions. Even if, at first glance, when looking at that RBAC role name, you might expect only dataActions and notDataActions.

Custom roles

I would say that in 90% of scenarios, the built‑in roles are sufficient to fulfill the security requirements of your project. However, there may be cases where you need to create your own role with very specific requirements.

As we already know, an RBAC role is simply a JSON definition. Creating a custom role therefore means creating that definition, adjusted to your project’s needs. You can do this in various ways, but the most convenient option at least in the beginning might be using the Azure Portal with the Add Custom Role feature and the Clone a role option. It helps you create the JSON definition without the need to do anything manually.

Cloning a role is very helpful because you usually need to narrow down the permissions of a built‑in role, making it a great starting point.

Why the separation exists?

The separation between control-plane and data-plane operations exists mainly due to these reasons:

• It prevents over privileging – someone who can consume data doesn’t automatically gain rights to reconfigure or delete the resource.
• It aligns with the principle of least privilege – ensuring that operational access is distinct from administrative control.
• It allows organizations to assign roles more precisely – e.g., applications can read from queues without being able to change their configuration.

Best practices

Below are a few helpful tips to keep in mind:

• Use built‑in roles first: They cover most scenarios and are tested by Microsoft for security and usability.
• Apply least privilege: Grant only the permissions required for a task. If a built‑in role is too broad, clone it to create a custom RBAC role and narrow its permissions.
• Separate duties: Assign administrative roles (control‑plane) and operational roles (data‑plane) to different identities where possible.
• Leverage assignable scopes: Restrict custom roles to specific subscriptions, resource groups, or resources to avoid accidental overreach.
• Document custom roles: Keep a clear record of why a custom role was created, what permissions it includes, and who should use it.

Summary

I hope that I clarified some of the key concepts around control‑plane and data‑plane permissions in RBAC in Azure. My goal was to show not just how they differ, but why the separation exists and how it helps you design a secure, manageable access model. I also hope that if you ever need to create a custom role, then knowing the JSON RBAC role definition will give you the confidence to do it.

In the next post we will talk about Managed Identities! Thanks for reading and see you there!