Open mitchdenny opened 10 months ago
Expands on: https://github.com/dotnet/aspire/issues/691
'Cosmos DB Operator' role: For Database/container management operations, please use mgmt SDK
For data operations (CRUD documents/items): 'Cosmos DB Built-in Data Contributor' ref: Configure role-based access control with Microsoft Entra ID - Azure Cosmos Db | Microsoft Learn
@mitchdenny - did #1583 fix this?
No it doesn't. For inner loop we still use connection string with account key. In fact I'm not sure this is a super high priority.
Enhance the Azure Cosmos DB provisioner to support token based auth.
Background
Currently the Aspire service-side components for CosmosDB support specifying a URI as the connection string which triggers its support for token-based authentication (great!). The problem is that the provisioner supplies a connection string, so we aren't able to exercise that token based auth flow in the inner loop.
It is easy enough to just supply the Cosmos DB URI in the connection string, the user identity that is used for token auth almost certainly won't have the roles it needs for the freshly configured account so their code can create databases, collections, and read/write items. This is something that the provisioner will need to handle.
The problem is that there is no top level role that we can assign that would grant a developer access. we need to define a custom role with specific permissions to unlock access. Some of these permissions may require knowledge of the specific databases being accessed although this isn't 100% certain.
We'll need to work with the Cosmos DB team to better understand the best permissions to give that enables the following:
If the answer is to automatically create a custom role we need to consider whether there are any implications of many developers running this provisioning logic and what we do to avoid collisions and whether we would pollute the namespace with random custom role definitions.