Support RBAC access control for cosmosDb

[harsimranmaan]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Azure reports the following best practice when checking CosmosDb usage for IPAM
Azure Cosmos DB accounts should use Azure Active Directory as the only authentication method

Describe the solution you'd like
Manual remediation:
Change your resource authentication method to RBAC. After RBAC is enabled, edit the configuration settings to enforce RBAC as the only authentication method.

Change the resources' authentication method from primary key to Azure Active Directory (AAD):

    Map all the resources that currently access to the Azure Cosmos DB account with keys or access tokens.
    Create an Azure Active Directory (AAD) identity for each of these resources:
        For Azure resources, you can [create a managed identity](https://learn.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview?WT.mc_id=Portal-Microsoft_Azure_Security) . You may [choose between system-assigned and user-assigned managed identities](https://learn.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview?WT.mc_id=Portal-Microsoft_Azure_Security#managed-identity-types).
        For non-Azure resources, [create an AAD identity](https://learn.microsoft.com/azure/active-directory/develop/howto-create-service-principal-portal?WT.mc_id=Portal-Microsoft_Azure_Security). 
    Grant each AAD identity the minimum permission it requires. When possible, we recommend you use one of the [2 built-in role definitions](https://learn.microsoft.com/azure/cosmos-db/how-to-setup-rbac?WT.mc_id=Portal-Microsoft_Azure_Security#built-in-role-definitions): Cosmos DB Built-in Data Reader or Cosmos DB Built-in Data Contributor.
    Validate that the new resource is functioning correctly. After new permissions are granted to identities, it may take a few hours until they propagate. When all resources are working correctly with the new identities, continue to the next step. 

[You can read more about configuring role-based access control with Azure Active Directory for your Azure Cosmos DB account](https://learn.microsoft.com/azure/cosmos-db/how-to-setup-rbac?WT.mc_id=Portal-Microsoft_Azure_Security#built-in-role-definitions).

Enforce RBAC as the only authentication method:
You may choose one of the two options listed below:
    You can use the az resource update powershell command:
    $cosmosdbname = "cosmos-db-account-name"
    $resourcegroup = "resource-group-name"
    $cosmosdb = az cosmosdb show --name $cosmosdbname --resource-group $resourcegroup | ConvertFrom-Json

    az resource update --ids $cosmosdb.id --set properties.disableLocalAuth=true --latest-include-preview

    Deploy these changes in your ARM template [to enforce RBAC as the only authentication method](https://learn.microsoft.com/azure/cosmos-db/how-to-setup-rbac?WT.mc_id=Portal-Microsoft_Azure_Security#disable-local-auth).

    [You can read more about using ARM templates on existing resources](https://learn.microsoft.com/azure/architecture/guide/azure-resource-manager/advanced-templates/update-resource?WT.mc_id=Portal-Microsoft_Azure_Security).

After these changes have been implemented, all access attempts that use primary/secondary key or access tokens authentication will be denied.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
This'll likely require minor code tweaks to move from using the primary key to AAD in the application.

[DCMattyG]

Hi @harsimranmaan, apologies as I am a little confused by the request.

For quite some time now, all new deployments of Azure IPAM use RBAC access for Cosmos DB and no longer use Access Keys. If you review the Bicep deployment for the Cosmos DB component, you can see that it is deployed exactly as you have described above:

https://github.com/Azure/ipam/blob/main/deploy/modules/cosmos.bicep

Is there something I'm missing perhaps?

[harsimranmaan]

Please see

ipam/engine/app/routers/common/helper.py

Line 27 in 4919aeb

credential=(globals.COSMOS_KEY if globals.COSMOS_KEY else managed_identity_credential),

, we still use the primary key to connect instead of the managed identity. Since the cosmos bicep modules writes to the key vault, the primary key is set and is used over managed identity. The azure recommendation is to disable the local auth and only use managed identity. Does this help?

[DCMattyG]

@harsimranmaan, this is in place for legacy customers who were originally using Shared Key credentials so the product continues to work until they migrate. All net-new deployments use Managed Identity w/ RBAC.

Does this make sense?

[DCMattyG]

I see what you're saying, this is the section that needs to be commented out:

https://github.com/Azure/ipam/blob/main/deploy/modules/cosmos.bicep#L93

That is what you were referring to, correct?

While you are correct that this DOES write the Key to KeyVault (which I will fix), the environment variable is no longer created in the App Service Bicep file, so the Shared Key is actually not used as the code you highlighted is looking for the environment variable, which it will not find.

[harsimranmaan]

The cosmosdb setting to not use local auth would also need to be set per the recommendations. Combined with dropping the key, it should be enough I think

[DCMattyG]

Understood, will add both in the next release. Thanks @harsimranmaan 👍

[harsimranmaan]

This has been addressed in the latest release. Feel free to close it @DCMattyG

[DCMattyG]

Hi @harsimranmaan, it is partially implemented.

I haven't added the Local Auth component just yet as I'd prefer have an associated document explaining how to gain Data Plane access should users need to view the Cosmos DB contents within the Azure Portal. Today this can only be done via PowerShell or CLI, so I don't want anyone to get stuck once this flag gets added to future deployments.