[receiver/azuremonitor] Add support for azureauthextension

[constanca-m]

Component(s)

receiver/azuremonitor

Is your feature request related to a problem? Please describe.

This is related to the issue #38908.

The azureauthextension implements the interface azcore.TokenCredential. So it can be used instead of creating a new azure identity using auth and any related fields.

Using the azureauthextension, the token credential can be shared among multiple receivers, instead of creating identities for each receiver used.

Describe the solution you'd like

The proposed feature would require either auth and its related fields to be filled, or token_provider (I have used token_provider name, since auth is taken). Once the receiver starts, it looks for that extension and then uses it to get credentials. The configuration using azureauthextension with the receiver would be a bit like this (very simple set up):

receivers:
  azuremonitor:
    discover_subscriptions: true
    token_provider: azureauth

extensions:
  azureauth:
    # See options in https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/extension/azureauthextension#azure-authenticator-extension
    managed_identity:
      client_id: ${CLIENT_ID}

exporters:
  debug:
    verbosity: detailed

service:
  extensions:
    - azureauth
  telemetry:
    logs:
      level: debug
  pipelines:
    metrics:
      receivers: [azuremonitor]
      exporters: [debug]

Describe alternatives you've considered

N/A

Additional context

You can find in my branch main...constanca-m:opentelemetry-collector-contrib:azuremonitorreceiver-add-support-azureauth the needed changes to support this feature. It's a rough draft, but everything should work well. Using the set up I shared before, you should be able to have the collector working well:

$ ./collector --config config.yaml 
2025-03-30T20:01:33.247+0200    info    service@v0.122.2-0.20250319144947-41a9ea7f7402/service.go:193   Setting up own telemetry...
2025-03-30T20:01:33.248+0200    info    builders/builders.go:26 Development component. May change in the future.        {"otelcol.component.id": "debug", "otelcol.component.kind": "Exporter", "otelcol.signal": "metrics"}
2025-03-30T20:01:33.248+0200    info    builders/extension.go:50        Development component. May change in the future.        {"otelcol.component.id": "azureauth", "otelcol.component.kind": "Extension"}
2025-03-30T20:01:33.249+0200    info    service@v0.122.2-0.20250319144947-41a9ea7f7402/service.go:260   Starting ...    {"Version": "v0.0.0", "NumCPU": 16}
2025-03-30T20:01:33.249+0200    info    extensions/extensions.go:40     Starting extensions...
2025-03-30T20:01:33.249+0200    info    extensions/extensions.go:44     Extension is starting...        {"otelcol.component.id": "azureauth", "otelcol.component.kind": "Extension"}
2025-03-30T20:01:33.249+0200    info    extensions/extensions.go:61     Extension started.      {"otelcol.component.id": "azureauth", "otelcol.component.kind": "Extension"}
2025-03-30T20:01:33.249+0200    info    azuremonitorreceiver/scraper.go:186     'token_provider' will be used to get the token credential       {"otelcol.component.id": "azuremonitor", "otelcol.component.kind": "Receiver", "otelcol.signal": "metrics"}     <-------- The new token_provider configuration
2025-03-30T20:01:33.249+0200    info    service@v0.122.2-0.20250319144947-41a9ea7f7402/service.go:283   Everything is ready. Begin running and processing data.
2025-03-30T20:01:34.249+0200    info    Metrics {"otelcol.component.id": "debug", "otelcol.component.kind": "Exporter", "otelcol.signal": "metrics", "resource metrics": 0, "metrics": 0, "data points": 0}
2025-03-30T20:01:34.250+0200    info            {"otelcol.component.id": "debug", "otelcol.component.kind": "Exporter", "otelcol.signal": "metric

[github-actions]

Pinging code owners:

• receiver/azuremonitor: @nslaughter @celian-garcia

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[celian-garcia]

Hello, it looks promising thank you!

Little comments:

• In the example you have a scope but it is not used right?
• knowing that azuremonitor receiver is still an alpha, I wouldn't be against a breaking change for the auth field, if you think it can reduce the code and simplify, please break!

[constanca-m]

In the example you have a scope but it is not used right?

The scope is needed to get the token the azureauthextension:

opentelemetry-collector-contrib/extension/azureauthextension/extension.go

Lines 156 to 158 in 4930224

	token, err := a.credential.GetToken(ctx, policy.TokenRequestOptions{
	Scopes: []string{a.scope},
	})

The scope is a tricky situation that I am in doubt myself, and I'm open to change.

Since azureauthextension is intended to work for all kinds of azure clients, there is not a scope that fits them all. I think the one that covers the most would be https://management.azure.com/.default, but then I fear two things:

1. That since this possible default scope does not fit all cases, it would make it confusing to use the azureauthextension. "Why is azureauthextension incapable of authenticating my requests?".
2. It gives too many permissions. Regarding the scopes for access tokens, Azure documentation mentions:

Developers should always abide by the principle of least privilege, asking for only the permissions they need for their applications to function.

For azure monitor, the default in previous azure SDK version was https://management.azure.com. I believe it remains the same of the current azure SDK: see this and this.

knowing that azuremonitor receiver is still an alpha, I wouldn't be against a breaking change for the auth field, if you think it can reduce the code and simplify, please break!

You are the codeowner, I leave this up to you 😄 I'm fine with both.

[celian-garcia]

• Regarding scope, ideally the GetToken shouldn't be called for azuremonitor receiver. We're using some Azure SDK clients that manage the token lifecycle themselves. All we need is azcore.TokenCredential to specify it to the client. I believe this is the trend for all clients of the official SDK. Maybe you can make the scope optional and if not specified, you don't call GetToken? To me there can be multiple calls to Azure in a components and each one could have their own token. This is quite complex to maintain with an extension.
• Regarding breaking change, I'm in favour of introducing a strong dependency with the extension. In other words remove completely the logic on the azuremonitor receiver that generates the azcore.TokenCredential, and rely fully on the extension. Even no config on azuremonitor receiver and a message saying "This component requires you to activate azureauth extension."

[constanca-m]

All we need is azcore.TokenCredential to specify it to the client. [...] Maybe you can make the scope optional and if not specified, you don't call GetToken?

The client for azure monitor is created from the function NewClient(credential azcore.TokenCredential, options *arm.ClientOptions). The token credential is the interface:

// TokenCredential represents a credential capable of providing an OAuth token.
// Exported as azcore.TokenCredential.
type TokenCredential interface {
	// GetToken requests an access token for the specified set of scopes.
	GetToken(ctx context.Context, options TokenRequestOptions) (AccessToken, error)
}

So while you are correct that we don't call the GetToken ourselves, it needs to be there as the azure SDK will use it internally. Does it make sense? The scope for that internal call would be https://management.azure.com/.default by default.

Regarding breaking change, I'm in favour of introducing a strong dependency with the extension.

👍

[constanca-m]

Actually @celian-garcia, you just made me realize that the scope can be handled better. I will open a PR and come back to you on this.

[celian-garcia]

There is probably something I miss there. I understand that you create implementation of the TokenCredential which will be used by the client. But this is the client that will choose the right scope to call.

Example from a code I'm calling

// s.cred would be your extension output.
// Scope is decided in the NewClient constructor
armSubscriptionClient, clientErr := armsubscriptions.NewClient(s.cred, s.clientOptionsResolver.GetArmSubscriptionsClientOptions()) 
...
// And then this call the http client and do the token generation if needed, probably using an http client with token round tripper integrated
opts := &armsubscriptions.ClientListOptions{}
armSubscriptionClient.NewListPager(opts)

[constanca-m]

When we create a client for the pager, each call will call GetToken internally.

But you calling attention to this situation made me realize that scope was not needed at all, and we could instead just call the GetScope from the azure identity that the extension creates.

I have created a new PR to update the code to completely rely on azure SDK for that: #39057.

So with this new change, all there is needed to use the azure auth extension would be:

receivers:
  azuremonitor:
    discover_subscriptions: true
    token_provider: azureauth

extensions:
  azureauth:
    # See options in https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/extension/azureauthextension#azure-authenticator-extension
    managed_identity:
      client_id: ${CLIENT_ID}

exporters:
  debug:
    verbosity: detailed

service:
  extensions:
    - azureauth
  telemetry:
    logs:
      level: debug
  pipelines:
    metrics:
      receivers: [azuremonitor]
      exporters: [debug]

So scope is no longer supported, and we can pass the extension to each new client.

Does this match your expectations now?

[celian-garcia]

That simplifies drastically the things indeed 😄 !
This is more than enough for me!
I can't wait to see all the useless code/tests removed from our receiver 🚀