My team is growing: how should I structure Cosmos DB access?
Azure Cosmos DB for NoSQL keeps control-plane management in Azure RBAC and item access in its own data-plane RBAC. Microsoft's guidance is to model access around jobs, not people: Entra groups, one managed identity per workload, the narrowest role and scope, and temporary elevation for production.
Key points
- Control-plane Azure RBAC and data-plane RBAC are separate; Azure Owner or Contributor grants no item access.
- The built-in Data Reader and Data Contributor roles cover most workloads, but Data Contributor includes delete.
- Assign roles to Entra security groups named for service, environment and responsibility, not to individuals.
- Give each application and deployment pipeline its own managed identity instead of sharing human groups.
- Scope data roles as narrowly as possible, at container or database level rather than the whole account.
- Anyone who can fetch an account key can bypass data-plane roles, so finish migrating clients before disabling local authentication.
Azure Cosmos DB for NoSQL has two separate permission systems: Azure RBAC for managing accounts, databases, containers and throughput, and the service's own data-plane RBAC for reading and writing items. Neither implies the other, so an Azure Contributor cannot read items and a data role cannot reconfigure the account.
Microsoft's advice is to model jobs, not people. Assign roles to Entra security groups such as cosmos-orders-prod-data-readers, give every workload its own managed identity, and start from the built-in Data Reader and Data Contributor roles at database or container scope. Cosmos DB Operator manages resources without granting key access. Keep production read-only with time-boxed elevation, and migrate key-based clients to Entra authentication before you disable local authentication.
Real-world use
- An orders API running as a managed identity that writes to one container but must never delete items.
- A reporting job that reads a reporting database with Data Reader while operational containers stay invisible to it.
- An SRE team that holds Cosmos DB Operator for diagnostics and gets temporary data access through PIM during an incident.
- A multi-environment subscription where developers get Contributor in dev but only read-only plus elevation in production.
Why it matters
Shared, broad permissions make every identity an account-wide risk; job-based roles with narrow scope keep the blast radius small when one credential leaks.