Azure Cosmos DB
An Azure NoSQL database service for app development.
How to use MSI workload identity to authenticate to CosmosDB Cassandra
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(9.6, 3%, 10%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJB%3C/text%3E%3C/svg%3E)
Jordan Bar (He/him/his)
0
Reputation points
Hello,
I've provisioned a CosmosDB Cassandra instance, have it configured with private endpoint. the DB is routable/accessible.
My question is about using an MSI (either Entra ID Group or a k8s federated Workload Identity to authenticate/authorize queries against the DB, using gocql library.
It is unclear how set the password in the Authenticator struct.
If I enable CosmosDB local-authentication, then of-course I can establish a connection, but that is using static-credentials, and the rotation of these credentials poses an operationl risk.
When compared to MSI-based authN/Z which is much more secure and streamlined.
Although I've assigned both the control-plane "DocumentDB Account Contributor" and the data-plane internal data-contributor, I'm getting a 403 when trying to authenticate.
I've tried using "azidentity.NewDefaultAzureCredential(nil).GetToken().Token" as the password, but to no avail.
Anyone else facing the same issue? or something I'm missing in CosmosDB AuthN/Z design?
Azure Cosmos DB
{count} votes
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(252.8, 60%, 34%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMK%3C/text%3E%3C/svg%3E)
Mahesh Kurva 6,850 Reputation points Microsoft External Staff Moderator2025-07-21T20:31:06.79+00:00 Greetings!!Cosmos DB does not natively support authentication via managed identity. Therefore, Service Connector uses the managed identity to retrieve the connection string, and the connection is subsequently established using that connection string.
For more information, please refer the document:
I hope this information helps. Please do let us know if you have any further queries.
-
Jordan Bar (He/him/his) 0 Reputation points
2025-07-21T22:08:01.2566667+00:00 Hello @Mahesh Kurva ,
Thank you for your quick response.
I've been using this method, and I'm sure you understand when I say that using shared credentials does not enable audit-trail and isolation. when these credentials are compromized, I'd need to rotate my entire (global) deployments to pickup an updated (rotated) set of credentials (which are still shared across all MSIs).In addition, I'll carefully say that the page you shared is missing the requirement that "local authentication" needs to be enabled (in my org we disable it by default.), also to clearly state the MSIs are not supported.
Lastly, while I understand the drive/push to use Azure DocumentDB, it should be doable and community friendly to write an AzureAuthenticator (implements IAuthenticator) and enable native Cassandra connections to levrage native Azure RBAC.
Best,
Jordan -
Oury Ba-MSFT 21,101 Reputation points Microsoft Employee Moderator2025-07-24T23:05:33.86+00:00 @Jordan Bar (He/him/his) Thank you for reaching out and sorry for the issue you are facing while connecting to an Azure Cosmos dB for Cassandra using SMI. Could you please share the complete error message. I know you already mentioned above 403.
-
Jordan Bar (He/him/his) 0 Reputation points
2025-07-24T23:16:39.1333333+00:00 Hi @Oury Ba ,
Thank you for the follow up and apologies if my previous message was a bit forward/strong. I'm a platform engineer myself and am thinking at large scale and focus on developer-friendly/secure services.
- Certificate errors - I was able to find a valid path to securely connect to CosmosDB Cassandra using a secure channel, its was a golang tls.Config.ServerName field that I added.
- 403 errors - our Azure TAM confirmed that CosmosDB Cassandra does not support data-plane RBAC for MSIs (for example, k8s workload-identity), thus forcing users to use the primaryMasterKey as password, resulting in shared and static credentials. this is bad practice and this is the point where I was surprized that CosmosDB service forced me to use shared/static credentials.
- Due to our desire to develop a secure application, we are forced to invest the time and switch over to CosmosDB NoSQL API (still using golang), hoping to see data-plane RBAC available for MSIs (as ur TAM confirmed, but until I don't see it running/working......)
- Lastly, Azure documentation for CosmosDB Cassandra can be improved by clearly stating at the top that data-plane RBAC is not supported, as well as clearly stating that it is NOT integrated with Azure Entra ID (so MSIs can't use it)
Coming from an AWS background, this is a learning curve.
Let me know if you have any questions, for now, I don't have errors on my end.
-
Oury Ba-MSFT 21,101 Reputation points Microsoft Employee Moderator
2025-07-31T20:49:10.71+00:00 Thank you for the update and for sharing the solution.
Sign in to comment
Sign in to answer