Chapter 22 Azure I: CLI, Identity & Data Planes
Azure from the command line: the az CLI and its queries, who you are (Entra ID, service principals, managed identities), who may do what (RBAC), and why being Owner does not let you read a Key Vault secret.
In plain words
Think of a big office building. At the front desk, a guard checks your ID card and gives you a visitor badge: that's proving who you are. The badge then opens only certain doors: your floor, the kitchen, not the server room. Some rooms, like the safe, have their own lock with a separate list, so even the building manager needs a key to that list. And every room has an address: building, floor, room number.
Azure works like that. Entra ID is the front desk that proves identity and issues tokens. Azure RBAC decides which doors a token opens, at which scope: subscription, resource group or resource. Key Vault and Storage are the rooms with their own data-plane locks. az is how you walk around the building and check all of it from a terminal.
Why it matters on call
Your team's Kubernetes clusters at work live inside Azure, and almost every Azure problem you'll touch as a platform engineer is an identity or permission problem: a pod that can't read its Key Vault secret, a pipeline that gets AuthorizationFailed, a role assignment that "does nothing" because it was made against the wrong ID, a storage account where anyone with Contributor can read everything through the keys. This chapter gives you the model to debug those in minutes.
It also matches how your team works: Terraform creates everything, and az is how you look, verify and do break-glass work. It comes after Terraform and Kubernetes because it connects them: workload identity ties a Kubernetes ServiceAccount to an Azure identity, and every resource here has an azurerm_* twin. Networking and Azure's managed Kubernetes follow in the next chapter.
Lessons
- What `az` actually talks to
- Output formats: json, table, tsv, yaml
- JMESPath: --query properly
- Entra ID: users, apps, service principals
- Managed identities: system-assigned vs user-assigned
- Azure RBAC: roles, scopes, inheritance
- Groups, custom roles and just-in-time access
- Key Vault: two permission models, one data plane
- From Key Vault into a pod: the Secrets Store CSI driver
- Storage accounts, blobs, and who is allowed in
- Managed disks (RWO) and Azure Files (RWX) for Kubernetes
25 hands-on labs (missions, incidents and drills) run in the terminal: Open this chapter in the terminal Free, in your browser - a real Ubuntu terminal to try it in, with missions that check your work.
Questions people ask
Why learn az if everything is created with Terraform?
Because you still need to look at Azure quickly and precisely: verify what Terraform created, find the object ID of an identity, check who has which role at which scope, read the exact error. Pipelines also run az checks, and at 3am when the pipeline itself is broken, the CLI is your break-glass tool. The rule in this block: nothing created from the portal, everything in Terraform, az and the portal for looking.
What is the difference between a tenant and a subscription?
The tenant is the Entra ID directory: users, groups, service principals and managed identities. Resources don't live in it. A subscription is where resources live, the billing unit and the usual RBAC boundary, and it trusts exactly one tenant. One tenant typically has many subscriptions, for example separate dev and prod subscriptions, because a subscription is a blast radius you can actually enforce with RBAC and policy.
What does control plane versus data plane mean in Azure?
The control plane is Azure Resource Manager at management.azure.com: creating, configuring and deleting resources, like creating a vault or scaling a node pool. The data plane is the service's own endpoint for what's inside: secrets at <vault>.vault.azure.net, blobs at <account>.blob.core.windows.net, the Kubernetes API of a cluster. They are authorised separately, through actions and dataActions in role definitions, which is why Owner can manage a vault but not read its secrets.
Is Entra ID the same as Active Directory?
No. Entra ID, formerly Azure Active Directory, is a cloud identity provider that issues OAuth 2.0 and OpenID Connect tokens over HTTPS. On-premises Active Directory Domain Services is a different product built on Kerberos, LDAP and domain controllers. Many companies sync their on-prem AD users into Entra ID, which is why the names were confused, and Microsoft renamed Azure AD to Entra ID in 2023 partly for that reason.
Why does this chapter keep saying "object ID" versus "client ID"?
Because they identify different things and mixing them up is a very common cause of broken access. The client ID, or appId, identifies an application when it signs in, and is what a workload uses to pick its identity. The object ID of the service principal or managed identity is what RBAC assignments point at. Give the wrong one to --assignee-object-id and the assignment points at nothing.