Part 2 of 3: Where resource deployment meets financial authority and how to govern it
In Part 1, we established the foundational model: Azure operates on three completely separate permission planes, Entra (identity), RBAC (resources), and Commerce (billing). A role in one plane grants zero access in the others.
That model is clean in theory. But in practice, the planes collide. And when they do, teams get confused, purchases stall, and governance gaps appear.
This post covers the biggest collision point: Marketplace, where resource deployment meets financial authority. We'll also dig into Managed Identity (the one construct that genuinely bridges two planes), ABAC (advanced conditional governance within the resource plane), and the five-step Marketplace approval workflow every digital-native company should adopt.
Marketplace: Where the resource and billing planes intersect
Marketplace is the most common collision point between Azure's permission planes. Here's why: deploying an Azure resource and purchasing a Marketplace SaaS product feel like the same action from the Portal, but they are governed by completely different permission systems.
Deploying resources ≠ Purchasing SaaS
A Contributor can deploy any native Azure resource: VMs, Storage, AKS, Networking, Databases, Azure OpenAI. These are resource plane operations governed by RBAC.
But purchasing a third-party SaaS product through Marketplace — Datadog, Snowflake, Elastic, Confluent, MongoDB Atlas, is a commercial transaction. It creates a financial obligation between your organization and a vendor. That's the billing plane.
- Deploying → RBAC (Resource Plane)
- Purchasing → Commerce (Financial Plane)
The marketplace permission model
| Action | Requires RBAC? | Requires billing role? |
|---|---|---|
| Deploy a VM | ✅ Yes | ❌ No |
| Deploy AKS cluster | ✅ Yes | ❌ No |
| Deploy Azure OpenAI | ✅ Yes | ❌ No |
| Deploy Datadog agent extension | ✅ Yes | ❌ No |
| Deploy Confluent cluster (Azure-native) | ✅ Yes | ❌ No |
| Purchase Datadog SaaS plan | ❌ No | ✅ Yes |
| Purchase Snowflake SaaS | ❌ No | ✅ Yes |
| Accept Confluent SaaS contract | ❌ No | ✅ Yes |
| View Snowflake private offer | ❌ No | ✅ Yes |
| Approve Marketplace private offer | ❌ No | ✅ Yes |
This is why engineers often ask:
"Why can't I buy Snowflake? I'm an Owner."
Because Owner has no financial authority. Owner is the highest role in the resource plane, but Marketplace SaaS purchases are commercial transactions that require billing plane permissions. These are different systems.
The subtlety: Azure-Native vs. SaaS
Some vendors have both Azure-native integrations and SaaS offerings, which makes this even more confusing:
- Datadog agent extension: deploys as an Azure resource → RBAC ✅
- Datadog SaaS plan: creates a billing relationship → Commerce ✅
- Confluent for Azure: deploys Kafka as an Azure resource → RBAC ✅
- Confluent Cloud SaaS contract: financial commitment → Commerce ✅
When an engineer deploys a Datadog agent via the Portal, everything works. When they try to subscribe to the Datadog SaaS plan, they hit a wall. Same vendor, same Portal, different permission plane.
The five-step marketplace purchase workflow
For digital natives operating with financial governance, every Marketplace purchase should follow this workflow:
Step 1: Engineer requests a SaaS or marketplace resource
The request should include: why it's needed, expected cost, impact on MACC, preferred vendor, and alternatives considered.
Step 2: Finance reviews commercial implications
Finance checks: MACC impact (does this purchase count toward the commitment?), budget alignment, available discounts (private offers), vendor validation, and contract terms.
Step 3: Billing role executes the purchase
Billing Account Owner or Contributor completes the transaction in the Portal. This is a billing plane operation.
Step 4: Engineering deploys or configures the resource
SaaS connector setup, private offer entitlement, RBAC for workload integration, data pipelines and integration. This is a resource plane operation.
Step 5: Cost monitoring activated
Alerts configured, budgets set, tagging applied, forecasting enabled.
This five-step workflow is simple, but most digital natives skip it and end up with surprise invoices, unapproved vendor commitments, or MACC burn they didn't plan for.
The one cross-plane bridge: Managed Identity
If the three-plane model is about separation, Managed Identity is the one construct that genuinely bridges two of those planes.
A Managed Identity is an Entra identity tied to an Azure resource and authorized via RBAC. It lets Azure workloads authenticate to other Azure services without storing credentials in code, environment variables, or configuration files.
The cross-plane flow
| Step | Plane | What happens |
|---|---|---|
| 1. Identity created | Entra (Identity) | A service principal is registered in the directory |
| 2. Access authorized | RBAC (Resource) | Role assignments grant access to specific resources |
| 3. Identity used | Runtime (Resource) | The workload requests a token from Entra and calls the target service |
No secrets. No passwords. No key rotation. The identity lifecycle is managed by Azure itself.
AI workload examples
For digital natives building AI applications, Managed Identity is essential:
| Scenario | Source | Target | RBAC role needed |
|---|---|---|---|
| App calls Azure OpenAI | App Service / Container App | Azure OpenAI | Cognitive Services OpenAI User |
| App reads secrets | App Service / Container App | Key Vault | Key Vault Secrets User |
| App reads/writes blobs | App Service / Container App | Storage Account | Storage Blob Data Contributor |
| AKS pod calls AOAI | AKS (Workload Identity) | Azure OpenAI | Cognitive Services OpenAI User |
| AKS pod reads secrets | AKS (Workload Identity) | Key Vault | Key Vault Secrets User |
| Function processes events | Azure Function | Event Hub | Azure Event Hubs Data Receiver |
| Pipeline reads training data | ML Workspace | Storage Account | Storage Blob Data Reader |
System-Assigned vs. User-Assigned
System-assigned: Tied to a single resource. When the resource is deleted, the identity is deleted. Best for simple scenarios with one resource accessing one or a few target services.
User-assigned: Created as a standalone resource. Can be assigned to multiple resources. Best for shared identity across microservices, AKS Workload Identity, or when the identity must persist independently.
AKS Workload Identity
AKS Workload Identity deserves special mention, it's the most common Managed Identity pattern in digital-native companies running Kubernetes:
- A User-Assigned Managed Identity is created in Azure
- A Kubernetes Service Account is annotated with the identity's client ID
- A Federated Identity Credential links the K8s service account to the Managed Identity
- RBAC role assignments grant the Managed Identity access to target resources
- At runtime, the pod uses the service account to get an Entra token via workload identity federation
This is Entra + RBAC + Kubernetes working together: identity plane creates the trust, resource plane authorizes the access, and the workload uses it at runtime.
Key insight: Managed Identity bridges Entra and RBAC, but never touches the third plane (billing). No identity, managed or otherwise, can see MACC credits or approve Marketplace purchases.
Advanced: Attribute-Based Access Control (ABAC)
ABAC extends RBAC with conditions based on resource attributes (tags), principal attributes, and request context. It is not a separate permission system, it's an enhancement to the resource plane.
For example, you can write a role assignment that says: "Allow Contributor access only to resources tagged Environment = Dev" or "Allow read access only to storage blobs under a specific path prefix."
ABAC is particularly useful for:
- Multi-tenant SaaS applications that need tenant isolation at the resource layer
- Regulated workloads that require fine-grained access control beyond what standard RBAC scopes provide
What ABAC cannot do: grant billing access, override Entra roles, access MACC, or purchase Marketplace products. It operates entirely within the RBAC resource plane.
For implementation details, see: Azure RBAC Conditions (ABAC)
References
- Azure RBAC Overview
- Managed Identities Overview
- AKS Workload Identity
- Marketplace Purchases & Invoicing
- Private Offers in Azure Marketplace
- Billing Roles (Microsoft Customer Agreement)
- Azure RBAC Conditions (ABAC)
What's Next → We've now covered the three-plane model (Part 1) and the biggest collision points: Marketplace, Managed Identity, and ABAC. In Part 3, we get tactical: the 7 anti-patterns to avoid, recommended role structures for Engineering, Finance, and Security teams, RACI templates, and the 10 core governance principles every scaling organization should adopt.
Microsoft