Will Percey — Portfolio

How Azure RBAC Works

personSecurity PrincipalWho

admin_panel_settingsRole DefinitionWhat

targetScopeWhere

assignment_turned_inRole AssignmentAccess Granted

Security Principals

A security principal is an object that represents a user, group, service principal, or managed identity that is requesting access to Azure resources.

User

Individual in Entra ID
Internal or guest (B2B)
Can have multiple role assignments

Group

Security or Microsoft 365 group
Members inherit group's roles
Best practice for scale

Service Principal

Identity for applications
App registrations
Automation & CI/CD

Managed Identity

Azure-managed credentials
System or user-assigned
No secrets to manage

Role Definitions

A role definition is a collection of permissions. It lists the actions that can be performed, such as read, write, and delete. Roles can be built-in or custom.

Fundamental Built-in Roles

Role	Description	Actions	Use Case
Owner	Full access including RBAC	`*`	Subscription admins, resource owners
Contributor	Create/manage all resources	`*` except role assignments	Developers, operators
Reader	View all resources	`*/read`	Auditors, support, monitoring
User Access Administrator	Manage user access only	Role assignments only	Delegated RBAC management

Role Definition Structure

Permission Types

Actions - Control plane operations (e.g., Microsoft.Compute/virtualMachines/read)
NotActions - Excluded control plane operations
DataActions - Data plane operations (e.g., blob read)
NotDataActions - Excluded data plane operations

Action Format

{Company}.{ProviderName}/{resourceType}/{action}

Examples:
Microsoft.Compute/virtualMachines/read
Microsoft.Storage/storageAccounts/write
Microsoft.Authorization/roleAssignments/*

Scope & Inheritance

Scope is the set of resources that the access applies to. Role assignments at a parent scope are inherited by child scopes.

account_treeManagement Group

→

credit_cardSubscription

→

inventory_2Resource Group

→

memoryResource

Permissions flow down - assignments at higher scopes apply to all children

Exam Notes

Assign roles at the highest appropriate scope to reduce management overhead. A Reader role at subscription level gives read access to all resources in that subscription.

Key Limits

Max 4,000 role assignments per subscription
Max 500 role assignments per management group
Max 5,000 custom roles per tenant

Custom Roles

When built-in roles don't meet your needs, create custom roles with specific permissions. Custom roles can be scoped to management groups, subscriptions, or resource groups.

When to Use Custom Roles

Built-in role grants too many permissions
Need to combine permissions from multiple roles
Require specific resource type access
Compliance requires least-privilege

Best Practices

Start with built-in, customize only when needed
Use NotActions to exclude specific permissions
Define AssignableScopes carefully
Document purpose and permissions

Custom Role JSON Structure

{
  "Name": "Virtual Machine Operator",
  "Description": "Can start, stop, and restart VMs",
  "Actions": [
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/powerOff/action",
    "Microsoft.Compute/virtualMachines/restart/action",
    "Microsoft.Compute/virtualMachines/read"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/{subscription-id}"
  ]
}

Deny Assignments

Deny assignments block users from performing specific actions even if a role assignment grants access. Deny takes precedence over allow.

How Deny Works

Attached to resources at a scope
Evaluated after role assignments
Deny always wins over allow
Cannot be created directly by users

Created By

Azure Blueprints - Protect managed resources
Azure Managed Applications - Publisher protection
Azure Lighthouse - Cross-tenant restrictions

Access Evaluation Order

Check deny assignments → If denied, access blocked
Check role assignments → If allowed, access granted
No matching assignment → access denied (implicit deny)

Privileged Identity Management (PIM)

PIM provides time-based and approval-based role activation to reduce the risks of excessive, unnecessary, or misused access. It's a feature of Microsoft Entra ID Premium P2.

Just-in-Time Access

Users activate roles only when needed, for a limited time period (e.g., 8 hours).

Approval Workflow

Require approval from designated approvers before role activation.

MFA Enforcement

Require multi-factor authentication to activate any role.

Access Reviews

Periodic reviews to ensure users still need their role assignments.

Audit History

Complete audit trail of all PIM activities for compliance.

Notifications

Email alerts when privileged roles are activated.

Eligible vs Active Assignments

Assignment Type	Description	Access
Eligible	User can activate the role when needed	No access until activated
Active	User has the role without activation	Immediate, permanent access
Time-bound Active	Active for a specific time period	Access expires automatically

Best Practices

Use Groups

Assign roles to groups, not individuals. Easier to manage and audit.

Least Privilege

Grant only the permissions needed. Start restrictive, add as needed.

Appropriate Scope

Assign at the highest scope that makes sense, but no higher.

Use PIM

For privileged roles, require just-in-time activation.

Regular Reviews

Periodically review role assignments. Remove stale access.

Built-in First

Use built-in roles when possible. Custom only when necessary.

Quick Reference

Concept	Description	Example
Security Principal	Who is requesting access	User, Group, Service Principal, Managed Identity
Role Definition	What actions are allowed	Owner, Contributor, Reader, Custom
Scope	Where the access applies	MG, Subscription, RG, Resource
Role Assignment	Principal + Role + Scope	"DevTeam group is Contributor on Prod-RG"
Deny Assignment	Block specific actions	Blueprints, Managed Apps
PIM	Just-in-time privileged access	Eligible assignments, approval workflow