How does Cosmos DB handle security and access control?

Cosmos DB provides multiple layers of security: network isolation, authentication, and fine-grained authorization.

Network-level security: By default, Cosmos DB accounts accept connections from all networks. You can restrict access using:

• IP firewall rules — Allowlist specific IP addresses or ranges
• Virtual Network (VNet) service endpoints — Restrict to specific Azure VNet subnets
• Private Endpoints — Use Azure Private Link to expose Cosmos DB on a private IP inside your VNet, blocking all public internet access

Authentication: Two models are available:

• Primary/secondary account keys — 512-bit HMAC keys that grant full read-write or read-only access to the entire account. Simpler but less granular. Avoid hardcoding in application code; store in Key Vault.
• Azure Active Directory (AAD) RBAC — Assign built-in or custom roles to AAD identities (users, service principals, managed identities). Preferred for production because keys can be rotated independently, access is granular per container, and there is a full audit trail in Azure Monitor.

Built-in AAD roles:

• Cosmos DB Built-in Data Reader — Read-only access to data
• Cosmos DB Built-in Data Contributor — Read-write access to data

Custom roles can be defined with granular permissions at the container level using the Azure RBAC JSON definition.

Encryption: All data is encrypted at rest using AES-256 by default (Microsoft-managed keys). Customer-managed keys (CMK) via Azure Key Vault are supported for compliance scenarios. All data in transit is encrypted with TLS 1.2+.

Managed Identities: The recommended pattern for applications running in Azure (VMs, App Service, Functions) is to use a system-assigned or user-assigned managed identity assigned the Cosmos DB RBAC role — no key management required.