Identity & governance

Identity & Governance — who you are vs. what you can do

Mental model: two independent questions run Azure access. Authentication asks "who are you?" — answered by Microsoft Entra ID (cloud identity). Authorization asks "what can you do?" — answered by Azure RBAC. A third gate, Azure Policy, asks "is this configuration even allowed?" Conflating these is the classic mistake: mix them up and you either lock people out or hand out the keys to the whole cloud.

Note the name: it is Microsoft Entra ID (or "Entra ID"), NOT "Azure AD" / "Azure Active Directory" — that phrasing is outdated. Microsoft Entra is the product family; Entra ID is the identity service within it.

1 · Microsoft Entra ID — the identity service
    Cloud identity and access management: users, groups, app registrations, SSO, MFA, Conditional Access.
    Every tenant is an Entra tenant. Entra ID proves WHO you are; it does not grant access to Azure resources.

2 · Azure RBAC — a role assignment is always three parts
    A role assignment = security principal + role definition + scope.
      - security principal  -> WHO   (a user, group, service principal, or managed identity)
      - role definition     -> WHAT  (a set of permitted actions)
      - scope               -> WHERE (the resource hierarchy level it applies to)
    Fundamental built-in roles:
      Owner                        -> full access, including managing others' access
      Contributor                  -> manage everything except granting access
      Reader                       -> view only
      User Access Administrator    -> manage others' access, but not the resources
      (newer) Role Based Access Control Administrator -> manage role assignments with less privilege than Owner

3 · Assign a role at a scope  (real az CLI shape)
    az role assignment create \
      --assignee user@org \
      --role Reader \
      --scope /subscriptions/<sub>/resourceGroups/rg-app
    # --assignee = the security principal, --role = the role definition, --scope = where it applies.

4 · Scope nests and inherits DOWNWARD — this is why RBAC scales
    Management Group  ->  Subscription  ->  Resource Group  ->  Resource
    Assign a role at a higher scope and it flows to everything beneath it.
    Assign Reader at the subscription -> it applies to every resource group and every resource under it.
    That is why you don't need thousands of individual grants.

5 · Resource hierarchy (the same nesting, for governance)
    Management Groups  ->  Subscriptions  ->  Resource Groups  ->  Resources
    You shape this tree with management groups over subscriptions, then apply policy and access broadly at the top.

6 · RBAC vs. Azure Policy — two independent gates (the #1 gotcha)
    RBAC   = WHO can do WHAT.        (does this principal have the action at this scope?)
    Policy = WHICH configurations are allowed.  (effects: deny / audit / deployIfNotExists / modify ...)
    Policy enforces configuration compliance, so it BLOCKS a non-compliant RESULT even for a fully
    authorized user — e.g. a VM deployed to a forbidden region is denied no matter your RBAC role.
    Same request, two separate checks. Being authorized (RBAC) does not mean the config is allowed (Policy).

7 · Entra directory roles vs. Azure RBAC roles — don't conflate
    Entra ID (directory) roles  -> manage Entra resources (users, groups, app registrations in the tenant).
    Azure RBAC roles            -> manage Azure resources (subscriptions, resource groups, resources).
    They are separate systems. Global Administrator in Entra is not the same as Owner on a subscription.

8 · Cost governance
    Microsoft Cost Management  -> analyze and control spend.
    Budgets                    -> alert on a threshold or forecast.
    Tags                       -> attach key/value metadata to resources for cost allocation and reporting.

Verify:  az role assignment list --assignee user@org --scope /subscriptions/<sub>/resourceGroups/rg-app
         # confirm the principal actually has the role at the scope you expect.

Notes:
  - Say "Microsoft Entra ID", never "Azure AD" / "Azure Active Directory".
  - RBAC != Policy: RBAC controls who can act; Policy controls which configurations are allowed — Policy can
    block an authorized user's non-compliant result.
  - A role assignment always = security principal + role definition + scope. Missing any part, it isn't a grant.

Scope honesty: facts verified against official Microsoft Learn documentation, not run on a live Azure
subscription. The az commands are real command shapes (az CLI 2.86); results are illustrative.