How to use managed entities and service principals to control access to Azure resources (such as Cosmos DB)?

Question

Since my other post was getting too fragmented, let this posting focus on service principals and managed identities for azure kubernetes clusters and cosmosdb ...

This article "how-to-using-managed-identities-to-access-cosmos-db-data-via-rbac-and-disabling-authentication-via-keys" advocates using the DefaultAzureCredentials.

1. Please help me understand how DefaultAzureCredentials works to allow me access to my cosmosDB inside my ASP.NET application inside a kubernetes (AKS) replica as per this sample code from how-to-using-managed-identities-to-access-cosmos-db-data-via-rbac-and-disabling-authentication-via-keys: string cosmosUrl = "https://<Cosmos DB Account>.documents.azure.com:443/";
   CosmosClient client = new CosmosClient(cosmosUrl, new DefaultAzureCredentials());

What is the advantage of this approach over just supplying the account and URI directly as arguments to the Cosmos client? In both cases the resulting C# executable has the hard coded unencrypted account string in the ASP.NET executable image.

Now this sample (see azure.identity.defaultazurecredential) might be more secure, I'm not sure. What do I specify for the userAssignedClientId? Is this the managed identity I created and assigned to the cosmosdb? Because this managed idenity is assigned to the cosmosDB, are we granted access? Is assigning a role necessary as discussed in how-to-using-managed-identities-to-access-cosmos-db-data-via-rbac-and-disabling-authentication-via-keys?

2. Previously I have created a service principal, specified this service principal when creating my kubernetes cluster, granted this same service principal access to blob storage (using the azure portal) and specified this service principal with ClientSecretCredential and this worked (i.e.: allowed me access to the blob storage). Is there a way to grant access of this same service principal to my cosmosdb? How would I do that? The web portal for the CosmosDB does not seem to have a way to grant access to a specified service principal or managed identity.

Answer 1

@Siegfried Heintze

Firstly, apologies for the delay in responding here and any inconvenience this issue may have caused.

Your application is using the DefaultAzureCredentials class that is getting token for authentication for CosmosDB. According to the article you linked in the question, this has nothing to do with with AKS Provisioning or management.

AKS Cluster will be provisioned separately and is recommended to use a separate Managed Identity/Service Principle to isolate access permissions to your CosmosDB and AKS.

Please check this document for best practices around this.

Also, from your original post here, for your ask:

3. Now if I want my kubernetes replica set webapp to have access to this cosmos DB do I have to create the Kubernetes cluster with this service principal internal to this newly created managed identity?

NO, you don't need to.

Some SME's from Cosmos or Identity area should be able to clarify this further.

Hope this helps.
Please 'Accept as answer' if the provided information is helpful, so that it can help others in the community looking for help on similar topics.