Cosmos DB for NoSQL: can Entra execute-only access allow internal procedure writes while denying direct writes?

Question

Cosmos DB for NoSQL: can Entra execute-only access allow internal procedure writes while denying direct writes?

DAVID Thomas 20

We are evaluating a predeployed JavaScript stored procedure in one container/logical partition. We have not provisioned an account or tested this permission combination.

The proposed runtime Entra service principal would have only these data actions, scoped to the container:

Microsoft.DocumentDB/databaseAccounts/readMetadata
Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/executeStoredProcedure

Assume no additional inherited/group data grants, control-plane privileges, account keys or resource-token access. A separate identity deploys the reviewed procedure.

Can that procedure internally read, create and replace items while direct item create/replace/upsert/delete requests from the runtime principal remain denied? If not, please identify the minimal extra actions and whether those actions also permit direct item writes outside the procedure.
Does executeStoredProcedure cover all procedures in the container, or support individual-procedure scope? Please identify the privileges that allow procedure creation/replacement/deletion so we can exclude them from runtime access. Container-wide execution with a protected approved-code inventory may be sufficient; individual-procedure scope is not assumed.
Separately, the account would use strong default consistency and one write region. The procedure would update a shared gate and exact result atomically, aborting on any mandatory-operation failure. Does the procedure guide's strong-consistency caution indicate a correctness/support limitation for this usage, or performance/local-execution guidance? Please clarify with a current documentation reference.

We are asking about native Entra RBAC, not the REST documentation's All access mode. A minimal supported role/scope example would help plan a later isolated test; we are not asking for certification of our application authorization or recovery design.

0 comments

1 answer

Your answer

Answer 1

Hello

Yes, Azure Cosmos DB for NoSQL provides a separate Entra data-plane permission for executing stored procedures, without granting direct item-write permissions. Your proposed design aligns with that permission model. However the approach you describe is consistent with Azure Cosmos DB's native Entra RBAC model, with a few important limitations.

1)Execute-only access and internal writes

Microsoft documents executeStoredProcedure separately from item-level create, replace, upsert, and delete permissions.

Stored procedures can perform internal reads and writes transactionally. Therefore, your proposed role should allow executing a stored procedure while direct item-write requests remain denied.

But internal operations never undergo additional caller-level RBAC checks. I recommend validating this exact combination in an isolated test before relying on it as a security boundary.

Official data-plane permissions reference

2)Stored procedure scope and management

executeStoredProcedure applies to all stored procedures within the authorized container. Native Entra RBAC does not document individual-procedure or logical-partition-level scopes.

Procedure creation, modification, and deletion require separate Azure management-plane permissions:

Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/storedProcedures/write

Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/storedProcedures/delete

Keep these permissions restricted to your deployment identity.

3)Minimal custom role

{
  "RoleName": "Stored Procedure Executor",
  "Type": "CustomRole",
  "AssignableScopes": ["/"],
  "Permissions": [{
    "DataActions": [
      "Microsoft.DocumentDB/databaseAccounts/readMetadata",
      "Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/executeStoredProcedure"
    ]
  }]
}

Create this as a Cosmos DB native data-plane role and assign it to the runtime principal at:

/dbs/<database>/colls/<container>

Official RBAC configuration guide

Test that procedure execution succeeds while direct create, replace, upsert, and delete operations return 403 Forbidden.

4)Strong consistency and transactions

The statement that stored procedures aren't suggested with strong consistency is a recommendation, not an explicitly documented prohibition as ACID transactions for stored procedures within a single logical partition, with rollback when an exception occurs.

Queries within a stored procedure might not see changes made earlier in the same transaction. This matters for your shared-gate logic.

Ensure both updates use the same partition key, check asynchronous operation results, and throw on mandatory failures. Stored procedures also have a five-second execution limit.

Stored procedures and transactions
Your execute-only design is a reasonable least-privilege pattern. No additional direct item-write permissions are indicated by the published action definitions, but the exact internal authorization behavior should be tested or confirmed by the Cosmos DB product team before treating it as a guaranteed security boundary.

Documentation and cases:

Entra RBAC and stored procedure management limitations — Microsoft confirms management operations are separate from native data-plane RBAC.
Cosmos DB managed identity and custom RBAC roles — covers data-plane assignments and readMetadata requirements.