Using Managed Identity for Cassandra

Question

Using Managed Identity for Cassandra

Shreyas Ketkar 40 Microsoft External Staff

Hi

We are using Cassandra in our project with a requirement for use of managed identity.

When we were handed this project over, we were told that because Cassandra DB does not support managed identity, we cannot use Cassandra to satisfy this and we must use Native Cosmos. However, when trying to migrate to Native Cosmos, we encountered many issues with maintaining consistency.

We just wanted to check whether there is or was any impediment to using Cassandra to resolve this SFI item requiring managed identity, and whether it still exists.

Thanks in advance.

Pilladi Padma Sai Manisha 10,770 Reputation points Microsoft External Staff Moderator

2026-05-15T04:27:02.89+00:00

Hi @Shreyas Ketkar,
I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.
Shreyas Ketkar 40 Reputation points Microsoft External Staff

2026-05-15T05:19:24.4733333+00:00

Ok, so just to clarify it is impossible to make the disable local auth flag true whilst also keeping Cassandra?
Pilladi Padma Sai Manisha 10,770 Reputation points Microsoft External Staff Moderator

2026-05-18T10:42:15.18+00:00

Hi Shreyas Ketkar

Yes, at the moment, if you are using Azure Cosmos DB for Apache Cassandra, you cannot set “Disable local auth” to true and continue using standard Cassandra client authentication successfully.

That setting disables key-based/local authentication, but Cassandra API connections today still rely on account keys/connection strings at the CQL protocol layer. Since native Entra ID token-based authentication for Cassandra clients is not currently supported in the same way as the SQL (Core) API, disabling local auth would prevent typical Cassandra driver connections from authenticating.

So today this is effectively a platform limitation. Cassandra API currently requires local/key-based authentication for standard CQL connectivity, and enabling “Disable local auth” removes that authentication path. Native token-only authentication for Cassandra is not yet generally available.

Because of this, customers needing strict token-only authentication typically evaluate APIs such as SQL (Core) API that already support full Entra ID data-plane authentication.
Pilladi Padma Sai Manisha 10,770 Reputation points Microsoft External Staff Moderator

2026-05-22T09:18:51.4366667+00:00

Hi @Shreyas Ketkar,

I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.
Shreyas Ketkar 40 Reputation points Microsoft External Staff

2026-05-22T20:07:04.3166667+00:00

Hi @Pilladi Padma Sai Manisha

I think that confirms what we suspected.

Thank you for your checking.

Answer accepted by question author

0 additional answers

Your answer

Pilladi Padma Sai Manisha 10,770 Reputation points Microsoft External Staff Moderator

2026-05-15T04:27:02.89+00:00

Hi @Shreyas Ketkar,
I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.
Shreyas Ketkar 40 Reputation points Microsoft External Staff

2026-05-15T05:19:24.4733333+00:00

Ok, so just to clarify it is impossible to make the disable local auth flag true whilst also keeping Cassandra?
Pilladi Padma Sai Manisha 10,770 Reputation points Microsoft External Staff Moderator

2026-05-18T10:42:15.18+00:00

Hi Shreyas Ketkar

Yes, at the moment, if you are using Azure Cosmos DB for Apache Cassandra, you cannot set “Disable local auth” to true and continue using standard Cassandra client authentication successfully.

That setting disables key-based/local authentication, but Cassandra API connections today still rely on account keys/connection strings at the CQL protocol layer. Since native Entra ID token-based authentication for Cassandra clients is not currently supported in the same way as the SQL (Core) API, disabling local auth would prevent typical Cassandra driver connections from authenticating.

So today this is effectively a platform limitation. Cassandra API currently requires local/key-based authentication for standard CQL connectivity, and enabling “Disable local auth” removes that authentication path. Native token-only authentication for Cassandra is not yet generally available.

Because of this, customers needing strict token-only authentication typically evaluate APIs such as SQL (Core) API that already support full Entra ID data-plane authentication.
Pilladi Padma Sai Manisha 10,770 Reputation points Microsoft External Staff Moderator

2026-05-22T09:18:51.4366667+00:00

Hi @Shreyas Ketkar,

I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.
Shreyas Ketkar 40 Reputation points Microsoft External Staff

2026-05-22T20:07:04.3166667+00:00

Hi @Pilladi Padma Sai Manisha

I think that confirms what we suspected.

Thank you for your checking.

Answer 1

Hi Shreyas Ketkar,
Thankyou for reaching microsoft Q&A!
Currently, Azure Cosmos DB for Apache Cassandra does not support native token-based Azure AD / Managed Identity authentication at the Cassandra protocol (CQL) data plane in the same way the SQL (Core) API supports direct Entra ID authentication.

In practice, Cassandra clients still typically authenticate using Cosmos DB keys/connection strings when establishing CQL sessions.

What customers commonly do instead is:

Use a system-assigned or user-assigned Managed Identity for the application

Store Cosmos DB keys securely in Azure Key Vault or retrieve them programmatically Use Managed Identity to access Key Vault or management-plane operations securely Pass the retrieved key to the Cassandra driver at runtime

This approach removes hard-coded secrets from the application, but it is not the same as native token-based authentication directly between the Cassandra driver and Cosmos DB.

So the limitation is not with Managed Identity itself, but rather that the Cassandra API currently does not offer full first-class Entra ID authentication at the CQL protocol layer.

Because of this, some customers evaluate the SQL (Core) API or other APIs when strict token-only authentication requirements exist. However, migrating APIs can introduce application compatibility and consistency-model considerations, as you observed.

As alternatives today, you can consider:

Using Managed Identity together with Key Vault for secure secret retrieval Using Service Connector to simplify secret management and connection configuration Continuing with Cassandra API if preserving Cassandra compatibility and consistency behavior is more important than native token-based authentication

References:

Azure Cosmos DB managed identities documentation Service Connector for Cosmos Cassandra Azure Cosmos DB Cassandra RBAC documentation

Thanks.

Answer 2

Hello Shreyas Ketkar,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that you are having challenges using Managed Identity for Cassandra.

The best practices say:

“Cassandra DB does not support managed identity, therefore you must migrate to native Cosmos DB” is not accurate for Azure Cosmos DB for Apache Cassandra based on current Microsoft documentation. Azure Cosmos DB for Apache Cassandra now has a documented Microsoft Entra ID/RBAC path with Cassandra-specific data-plane role definitions and role assignments. - https://learn.microsoft.com/en-us/azure/cosmos-db/cassandra/how-to-connect-role-based-access-control, https://learn.microsoft.com/en-us/azure/cosmos-db/cassandra/reference-data-plane-security, and https://learn.microsoft.com/en-us/cli/azure/cosmosdb/cassandra/role/assignment?view=azure-cli-latest

My best advice for you is to keep the Cassandra API account, enable the application’s managed identity, disable key-based authentication, assign the managed identity the correct Cosmos DB Cassandra data-plane role, and verify with az cosmosdb cassandra role assignment list. Migration to Cosmos DB NoSQL API should only be considered for application/platform reasons, not as the primary solution for managed identity.

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.