Use DefaultAzureCredential for authenticate

[christinawongit]

azure-kusto-python/azure-kusto-ingest/tests/sample.py

Line 5 in 96f1db1

from azure.kusto.data import KustoConnectionStringBuilder

It is great to have different authenticate approaches for azure.kusto. However, it is quite tricky to switch between non-prod and prod environments.

For example, the scenario is to communicate with the other Azure resources (e.g. container app and azure data explorer) within the same tenant and the chosen authentication approach is managed identity. During development phase, the developers are working on their local machine and logged in with their own user accounts. So, would it mean they need to switch between embed user name and password in code, and switch to managed identity at deployment stage (would it mean user has to either make change in code every time or need to store unnecessary credential in Production environment)?

I understand we can use service principal (SPN), but the target resources of SPN seems to be third-party service provider (e.g. GitHub) and secret rotation is necessary. So, it would be my personal last preference in this case.

Therefore, would Your Team consider to use Azure.identity.DefaultAzureCredential for authentication?

[yogilad]

Hi @christinawongit ,

You can use any Azure Identity TokenCredential in combination with kcsb.with_token_provider().
The token value (string) should be passed as the result of a lambda function given to with_token_provider().
The resource string passed to the GetToken Api should be "https://kusto.kusto.windows.net/.default" (assuming you run in public cloud).

[yogilad]

Keeping this open as a backlog item to add explicit support for kcsb.with_azure_token_credential()

[mpicard]

I would also be interested in using DefaultAzureCredential or better support in general for azure.identity TokenCredentials for kusto

[AsafMah]

Since 4.1.0 there is an option to use any TokenCredential class, including DefaultAzureCredential.