Azure Monitor Query client library - The provided credentials have insufficient access to perform the requested operation (InsufficientAccessError)

in order to programmatically retrive some AppTraces and AppExceptions info from an Azure Application Insights Logs resource, we followed the instructions included in the following article advicing to adopt the new Azure Monitor Query client library for .NET to fulfill the purpose.

https://learn.microsoft.com/it-it/dotnet/api/overview/azure/Monitor.Query-readme?view=azure-dotnet

Strictly following the above article instructions (and using the DefaultAzureCredential object to authenticate), we managed to get the client library's LogsQueryClient object working fine in the local version of the developed web api (ASP .NET Core 6.0). And so, locally we are eable to fetch the logs info we need. But once we published the web api on the Cloud (under the same Azure subscription of the Application Insights target resource) we started to get the following error:

• Message: The provided credentials have insufficient access to perform the requested operation
• Status: 403 (Forbidden)
• ErrorCode: InsufficientAccessError

N.B. Surprisingly we didn't find any thread explaining, step by step how to fix the problem with specific reference to the new Azure Monitor Query client library.

To fix the issue, we tried replacing the class DefaultAzureCredential with the class ClientSecretCredential generating and assigning it a new client secret.

Here are the details concerning the steps we followed to implement the ClientSecretCredentials. In particular, we have:

1. Setup a new Azure AD Application.
2. Assigned it the required permissions ==> Data.Read (Read Log Analytics data - Granted from Admin).
3. Assinged to the Registered App (AAD Application) the Reader Role from the Application Insights Resource's Access control (IAM) section of the Azure Portal.
4. Created a new client secret for the AAD Application.
5. Created a new Azure Web API, on witch we Installed the Azure Monitor Query client library for .NET.
6. To retrive Logs data, we programmatically istantiated a new Azure.Identity.ClientSecretCredential object, assigning it the right tenantId, the client (application) ID of the AAD Application and the client secret previously generated for the App Registration.
7. In the Program.cs file of the web api we created a singleton instance of the class LogsQueryClient assigning it the above ClientSecretCredential object.
8. And finally we invoked the QueryWorkspaceAsync method of the class LogsQueryClient, passing it the WorkSpaceId of the Application Insights Resource (whom logs have to be read) and the query to retrive.

Unfortunately, replacing the class DefaultAzureCredential with ClientSecretCredential didn't work and the error message keeps to be the same.

N.B.

• The AAD User Type of the user who: developed and released the web api, registered the new Azure AD Application and granted it the necessary permissions is "Member".
• The above user, refers to the same tenant id as the resources he managed in the above steps (Web Api, AAD Application etc).
• During the release process of the web api, a new API Management service was specifically created by the same user releasing the app.

Here are the code snippets:

Program.cs

builder.Services.AddAzureClients(builder =>
{
    static LogsQueryClient func(LogsQueryClientOptions options)
    {
        options.Retry.Mode = Azure.Core.RetryMode.Exponential;
        options.Retry.MaxRetries = 5;
        var csc = new ClientSecretCredential(tenantId, clientId, clientSecret);
        return new LogsQueryClient(csc, options);
    }
    builder.AddClient<LogsQueryClient, LogsQueryClientOptions>(func);
    var credentials = new ClientSecretCredential(tenantId, clientId, clientSecret);
    builder.UseCredential(credentials);
});

Controller.cs (get logsQueryClient through dependency injection)

Response<LogsQueryResult> response = await logsQueryClient.QueryWorkspaceAsync(workSpaceId, query);

Thanks for your appreciated help. We finally managed to spot where the problem was.

After the point 3 listed in our original post: <<Assign to the Registered App (AAD Application) the "Reader Role" for the Application Insights acting from the resource's Access control (IAM) section of the Azure Portal.>>

... We omitted to do the same thing for the Log Analytics workspace. Each Application Insight resource refers infact to a specific Workspace. For that reason, it is necessary to assign the same reader role to the Registered App also for the above workspace. Log Analytics workspaces too have infact an Access control (IAM) section in the Azure Portal, just like the other resources.

Assigning this role to the AAD registered app the issue was fixed.