Authorization within Azure can be a bit confusing. A customer recently asked what the difference was between “Access Keys” and “Access Control” in Azure Storage. This illustrates a good point that can be more or less generalized to Azure itself.
These are two different authorization planes and that’s why they’re a bit confusing:
Managing the resource itself - setting policies, authorizing people in, rotating access keys, connecting to virtual network, etc., i.e. everything you would do on CLI or through the portal.
→ This is usually done through Access Control (IAM). You give permissions to users in AAD and they can do whatever they’re allowed to from there.
Accessing what’s inside the resource - accessing blobs, files, tables in SQL, secrets in KeyVault, remote-connecting to VMs, APIs in API Management, functions in Azure Functions, etc.
→ This is specific to the resource and usually done through either of two ways:
- Resource-specific credentials or access keys (such as storage access keys, Shared Access Signatures, SQL users, Azure Functions tokens, etc.) - which can be used in a way defined by the resource (SQL authentication, HTTP headers, …).
- Attributing roles to an Azure AD Principal in IAM (such as Blob reader in Storage, policies in Keyvault, or EasyAuth in Functions) - these usually rely on more standard OIDC authentication / Oauth Authorization, and on AAD identity or AAD app registrations, which by essence makes it slightly more controllable.
Example: Azure Storage
Managing the resource itself → done through IAM via ARM (Portal, CLI, Powershell, REST API)
Authorization to access blobs / files / queues / tables in a storage account – can be granted through 3 different ways:
Give access keys, which is a bazooka – with an access key you have access (including destructive access) to everything in the account
Shared access signatures, which are fine tuned: you generate a new SAS based on an access key, and give discrete permissions on an account, a blob container, or a single blob. SAS are also expiring after a configured time.
Give Azure AD permissions – which is done at the account level ; you can give reading or contributing accesses, and then it’s using Oauth2 from there on.