This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.

Objectives

As the document below mentioned, we can access Cosmos DB with Managed Identity.

How to use a system-assigned managed identity to access Azure Cosmos DB data | Microsoft Docs

Recently, a new feature, RBAC for Cosmos DB, is added and it allows us to configure fine-grain control to data operations for Cosmos DB with Azure Active Directory accounts.

Configure role-based access control for your Azure Cosmos DB account with Azure AD | Microsoft Docs

We don’t have to use any keys when using this feature to connect to Cosmos DB. Therefore, we can keep Cosmos DB more secure than ordinal style in connecting the DB.

The document mentioned above describes RBAC configuration with Service Principal, but Managed Identity also works. In this article, I elaborate how to configure RBAC for Cosmos DB with Managed Identity.

Topology and service components

In this article, I use the following configuration.

Function App (Read Only and Read/Write)
- Runtime: Java 11
- HTTP binding/trigger
Cosmos DB Java SDK v4
- The SDK is used in each Function App to interact with Cosmos DB.

Preparation

Function app

As I mentioned before, each Function App uses HTTP binding (trigger, output) and contains logic to interact with Cosmos DB. After creating a scaffold, we will add Cosmos DB interaction logic.

When accessing RBAC configured Cosmos DB with SDK, we have to get TokenCredential and use this credential to initialize CosmosClient or CosmosAsyncClient. TokenCredential is an interface and there are lots of implementation class of the interface, including ManagedIdentityCredential. So, we can also use Managed Identity to configure RBAC for Cosmos DB.

We can get a TokenCredential instance with the following code. DefaultAzureCredentialBuilder() is used in this example, but , ManagedIdentityCredentialBuilder() is also applicable.

TokenCredential tokenCredential = new DefaultAzureCredentialBuilder().build();

Next, we pass the TokenCredential instance to CosmosClientBuilder() to initialize CosmosClient or CosmosAsyncClient. As you can see, we don’t have to use any keys to create a client instance. We can create CosmosClient with the following code. As CosmosClient and CosmosAsyncClient is auto-closable, we should create the client instance surrounded with try-with-resources clause.

CosmosClient client = new CosmosClientBuilder() .endpoint(ACCOUNT_ENDPOINT) .credential(tokenCredential) .gatewayMode() .buildClient();

After that, codes corresponding to GET method and POST method are added.

GET : retrieve data from Cosmos DB.
POST: update or insert data passed in HTTP request body.

To check the response code from Cosmos DB, this response code is used in the “upsert” code as a HTTP status returned by Function App.

// Get data from HTTP body of request Track track = request.getBody().get(); // Update or insert data CosmosItemResponse<Track> cosmosItemResponse = cosmosContainer.upsertItem(track); // HTTP status code is used with response code from Cosmos DB HttpResponseMessage responseMessage = request.createResponseBuilder(HttpStatusType.custom(cosmosItemResponse.getStatusCode())) .header("Content-Type", "application/json") .body(track) .build();

When the implementation is completed, build Function Apps and deploy them to Azure.

Next, we create Managed Identity of each Function App. Navigate “Settings” > “Identity” in Azure Portal, and enable system assigned managed identity. As “Object (principal) ID” is used afterwards, I recommend you take a note of this ID. This operation is required in both Function Apps.

Cosmos DB

As usual, create Cosmos DB account, database, and container. In this article, database is named “Inventories”, and container is “Tracks”. Data listed below are populated in the container.

[ { "id": "4321", "type": "Hino", "purchaseDate": "2020/10/20", "remarks": "4t" }, { "id": "1234", "type": "Isuzu", "purchaseDate": "2020/11/20", "remarks": "4t" }, { "id": "6666", "type": "Fuso", "purchaseDate": "2020/12/20", "remarks": "4t" }, { "id": "1111", "type": "Volvo", "purchaseDate": "2021/09/20", "remarks": "4t" }, { "id": "1112", "type": "Volvo", "purchaseDate": "2021/09/20", "remarks": "4t" }, { "id": "1216", "type": "Volvo", "purchaseDate": "2021/09/20", "remarks": "4t" } ]

Next, two custom roles should be created for RBAC; one is “read only” role (MyReadOnlyRole), and the other is “read write” role (MyReadWriteRole). This operation is the same one in the document.

JSON file for read-only role configuration : role-definition-ro.json

{ "RoleName": "MyReadOnlyRole", "Type": "CustomRole", "AssignableScopes": ["/"], "Permissions": [{ "DataActions": [ "Microsoft.DocumentDB/databaseAccounts/readMetadata", "Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/read", "Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/executeQuery", "Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/readChangeFeed" ] }] }

JSON file for read-write role configuration : role-definition-rw.json

{ "RoleName": "MyReadWriteRole", "Type": "CustomRole", "AssignableScopes": ["/"], "Permissions": [{ "DataActions": [ "Microsoft.DocumentDB/databaseAccounts/readMetadata", "Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/*", "Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/*" ] }] }

Create custom roles MyReadOnlyRole and MyReadWriteRole with both JSON files. The following example describes how to create custom roles with Azure CLI.

resourceGroupName='<myResourceGroup>' accountName='<myCosmosAccount>' az cosmosdb sql role definition create -a $accountName -g $resourceGroupName -b @role-definition-ro.json az cosmosdb sql role definition create -a $accountName -g $resourceGroupName -b @role-definition-rw.json

To assign Managed Identity to each role, we have to acquire roleDefinitionIdof each role with the following command.

az cosmosdb sql role definition list --account-name $accountName -g $resourceGroupName

roleDefinitionId is corresponding to the attribute “name” in output JSON document.

[ { "assignableScopes": [ "/subscriptions/{subscription id}/resourceGroups/{resource group}/providers/Microsoft.DocumentDB/databaseAccounts/{CosmosDB account}" ], "id": "/subscriptions/{subscription id}/resourceGroups/{resource group}/providers/Microsoft.DocumentDB/databaseAccounts/{CosmosDB account}/sqlRoleDefinitions/{roleDefinitionId}", "name": "{roleDefinitionId}", "permissions": [ { "dataActions": [ "Microsoft.DocumentDB/databaseAccounts/readMetadata", "Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/*", "Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/*" ], "notDataActions": [] } ], "resourceGroup": "{resource group}", "roleName": "MyReadWriteRole", "type": "Microsoft.DocumentDB/databaseAccounts/sqlRoleDefinitions", "typePropertiesType": "1" }, { "assignableScopes": [ "/subscriptions/{subscription id}/resourceGroups/{resource group}/providers/Microsoft.DocumentDB/databaseAccounts/{CosmosDB account}" ], "id": "/subscriptions/{subscription id}/resourceGroups/{resource group}/providers/Microsoft.DocumentDB/databaseAccounts/{CosmosDB account}/sqlRoleDefinitions/{roleDefinitionId}", "name": "{roleDefinitionId}", "permissions": [ { "dataActions": [ "Microsoft.DocumentDB/databaseAccounts/readMetadata", "Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/read", "Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/executeQuery", "Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/readChangeFeed" ], "notDataActions": [] } ], "resourceGroup": "{resource group}", "roleName": "MyReadOnlyRole", "type": "Microsoft.DocumentDB/databaseAccounts/sqlRoleDefinitions", "typePropertiesType": "1" }, {...} ]

Finally, each roleDefinitionId is used to assign Function Apps to either MyReadOnlyRole role or MyReadWriteRole role. As you can see in the sample code below, Principal ID is object ID of each managed identity, which you would have taken notes in the previous section.

resourceGroupName='<myResourceGroup>' accountName='<myCosmosAccount>' readOnlyRoleDefinitionId = '<roleDefinitionId of MyReadOnlyRole>' ROprincipalId = '<Managed Identity Object ID for Function App, the app will be assigned to MyReadOnlyRole.>' az cosmosdb sql role assignment create -a $accountName -g $resourceGroupName -s "/" -p $ROprincipalId -d $readOnlyRoleDefinitionId readWriteRoleDefinitionId = '<roleDefinitionId of MyReadWriteRole>' RWprincipalId = '<Managed Identity Object ID for Function App, the app will be assigned to MyReadWriteRole.>' az cosmosdb sql role assignment create -a $accountName -g $resourceGroupName -s "/" -p $RWprincipalId -d $readWriteRoleDefinitionId

That’s it. Now let’s do test!

Test

At first, check behaviors by a Function App in MyReadOnlyRole. GET method works fine and get data stored in Cosmos DB.

However, POST method raises exception due to RBAC and returned 403. This is an expected behavior. Masked principal is equal to Principal ID of Managed Identity for read-only Function App.

rbac-ro-post1

We can see error messages via Log Streams in Azure Portal.

rbac-ro-post2

On the other hand, both GET and POST methods work fine in case of another Function App in MyReadWriteRole.

Use POST method to modify document...

And use GET method again to retrieve all data, we can see id:4321 modified.

Conclusion

We confirmed that RBAC configuration provided safe access to Cosmos DB for applications. Even if “upsert” or “delete” method is called from an application in read-only role, no data is modified and we can keep data safe and exception arises.

Demo code used in this article is available in the following GitHub repository.

anishi1222/CosmosDB_RBAC_Demo: Interact with RBAC configured Cosmos DB (github.com)

Configure RBAC for Cosmos DB with Managed Identity instead of Service Principal