Role-based access control (RBAC) answers three practical questions about an Azure resource: who can access it, what can they do, and where does that access apply? It helps keep permissions manageable as users and resources multiply. section 6.7
An RBAC assignment combines three elements:
- A security principal identifies who receives access, such as a user or application identity. section 6.7 section 6.9
- A role definition collects allowed actions, such as reading, writing, or deleting. section 6.7.2
- A scope identifies the area where that access applies. section 6.7
Start with a built-in role when one fits. Azure provides broad roles such as Owner, Contributor, and Reader, along with service-specific roles. Custom roles are possible, but their permissions and users can become harder to track. Grant only the access an identity needs; RBAC works alongside Entra ID authentication and a zero-trust approach. section 6.7.2 section 6.9
Database access without stray credentials
For Azure SQL, Entra ID can authenticate known users while role-based permissions limit access. The Azure CLI example below designates an Entra ID account as a SQL server admin; it is a setup step, not a complete RBAC role assignment. section 10.6.1
C:/> az sql server ad-admin create --resource-group BanningRG --server-name BanningBooksServer --display-name <EntraIDDisplayName> --object-id <EntraIDObjectId>
Shows the Azure CLI command for designating an Entra ID user as Azure SQL server admin using the account’s display name and object ID. section 10.6.1
