A2 - entra ID, RBAC & managed identities

WHO?
 │
 ▼
Microsoft Entra ID
 │
 │ authenticate
 ▼
Identity / token
 │
 ▼
WHAT CAN IT DO?
 │
 ▼
Azure RBAC
 │
 ├── role
 └── scope

• it contains identities/principals such as:

  • users
  • groups
  • applications/service principals
  • managed identities

• Azure RBAC can assign roles to these principals

• microsoft describes an Azure RBAC role assignment using three core components:

  • principal
  • role
  • scope: resource-group

• the principal is the identity receiving access which can be user, group, service principal, or managed identity

• a role is a collection of permissions, eg: reader, contributor, owner, storage blob data reader

• the scope defines where the permissions apply

• Azure supports four main scopes: management group, subscription, resource group, resource, where lower scopes inherit permissions from higher scopes

• the principle of least privilege is applied to limit scope to reduce the resources that could be affected if a principal were compromised

• a service principal is an identity representing an application/service in microsoft entra ID

• eg: github actions > service principal > microsoft entra ID > Azure

• user accounts must not be used for automation as the account will be tied to a particular person

• a managed identity provides an automatically managed identity for an Azure resource/service that can authenticate to Azure services that support microsoft entra authentication without storing credentials in code

• Azure manages important parts of the identity lifecycle

• they are of two types:

  • system-assigned: tied directly to an Azure resource, so useful when identity belongs specifically to one resource
  • user-assigned: a separate Azure resource that can be assigned to one or more resources, which is useful when several resources share the same identity

• managed identity is not permission by itself as it is only an identity so roles must be assigned (RBAC)

• after an application authenticates with entra ID, it obtains an access token that gets validated by the service

• as github actions is not an Azure resource, workload identity federation is used allowing github's identity token to be trusted by entra without maintaining a long-lived client secret