A principal is the identity attempting to authenticate to a resource. In Azure RBAC, a security principal is the “who” that receives permissions for Azure resources: a user, group, service principal, or managed identity. section 2.2 section 2.3.2
Authentication verifies the principal’s identity. The principal presents a credential, such as a password or certificate, and successful authentication produces tokens used to grant access to a resource. Avoid designs where every resource stores principal credentials: a breached resource can expose reused passwords to further attacks. section 2.2 section 2.2
Use the principal as the starting point for an Azure RBAC decision:
- Identify the user, group, application service principal, or managed identity that needs access. section 2.3.2
- Choose a role definition that states the allowed actions, such as read, write, or delete. section 2.3.2
- Create a role assignment that binds that principal and role definition at the required scope. section 2.3.3
- Remove the role assignment when access is no longer required. section 2.3.3
Granting application access
An application needing a storage account can be represented by a service principal; a managed identity can also be a security principal. Assign the needed role at the appropriate resource scope rather than treating the application itself as its permissions. section 2.3.2 section 2.3.3
This diagram links the three parts of an Azure RBAC grant: the security principal, role definition, and scope. section 2.3.3




