New component: azure authentication extension

[constanca-m]

The purpose and use-cases of the new component

This extension authenticator would work in a similar way googleclientauth extension.

Currently, there already several azure exporters and receivers, and each have their own authentication ways:

• azureblobreceiver: needs service_principal or connection_string
• azureeventhubreceiver: connection
• azuremonitorreceiver: service_principal, workload_identity, managed_identity, default_credentials.
• azureblobexporter: connection_string, system_managed_identity,
  user_managed_identity, service_principal.
• azuredataexplorerexporter: Service principal, managed identity, default.
• azuremonitorexporter: connection_string.

With this authenticator extension, we could have a common approach to all of them. This way we have:

• Only one configuration for all the Azure components.
• Supports different authentication methods (see below).
• Implements (auth.Server interface and auth.Client interface), so it can be used in both receivers and exporters.

Example of integration with some existent components:

• Before:

receivers:
  azureeventhub:
    connection: "..." # connection string is discouraged
    
exporters:
  azureblob:
    auth:
      connection_string: "..." # connection string is discouraged
  azuremonitor:
    connection_string: "..." # connection string is discouraged

• After:

extensions:
  # see in next section example configurations
  azureauth/blob:
  azureauth/monitor:
  azureauth/eventhub:

exporters:
  azureblob:
    auth:
      authenticator: azureauth/blob
  azuremonitor:
    auth:
      authenticator: azureauth/monitor

receivers:
  azureeventhub:
    name: ...
    namespace: ...
    auth:
      authenticator: azureauth/eventhub

We could start with the following options for authentication:

• Managed identity support for Azure resources
• Workload identity support for Kubernetes
• Service principal support with client secret/certificate for non Azure.
• And the default credentials. Discouraged for production. In azidentity, it is mentioned:

In production, it's better to use a specific credential type so authentication is more predictable and easier to debug.

Connection string is not mentioned for optimal security, so there will not be support for that.

See also recommended authentication approach. We will use the credentials to get the token.

Example configuration for the component

1. Managed identity:

extensions:
  azureauth:
    # resource defines the scope
    resource: "https://<...>.com/.default"
    managed_identity:
      # Types: user or system
      # See https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview#managed-identity-types.
        client_id: ""  # If empty then system-assigned, otherwise user-assigned

2. Workload identity:

extensions:
  azureauth:
    # resource defines the scope
    resource: "https://<...>.com/.default"
    workload_identity:
      tenant_id: "${AZURE_TENANT_ID}"
      client_id: "${AZURE_CLIENT_ID}"

3. Service principal support with client secret/certificate:

extensions:
  azureauth:
    # resource defines the scope
    resource: "https://<...>.com/.default"
    service_principal:
      tenant_id: "${AZURE_TENANT_ID}"
      client_id: "${AZURE_CLIENT_ID}"
      client_secret: "${AZURE_CLIENT_SECRET}" # or client_certificate_path

4. Default credentials, discouraged in production:

extensions:
  azureauth:
    # resource defines the scope
    resource: "https://<...>.com/.default"
    # See DefaultAzureCredential authentication order:
    # https://github.com/Azure/azure-sdk-for-go/blob/54746265023eaf4025bb53f3b869cae2489d1f27/sdk/azidentity/default_azure_credential.go#L48-L57
    use_default: true

Telemetry data types supported

Code Owner(s)

@constanca-m

Sponsor (optional)

@atoulme

Additional context

No response

[constanca-m]

Hi @mx-psi and @atoulme. Since you are codeowners of some of the existent azure components:

• Azure Blob Receiver - @mx-psi
• Azure Event Hub Receiver - @atoulme

Would any of you be willing to sponsor the authorization extension?

[atoulme]

I can sponsor this. Would that help share logic between all azure components?
@celian-garcia @hgaol would you benefit from this?

[hgaol]

Azure blob exporter can benefit, except for connection_string auth based on description. BTW, the resource(scopes) could be optional for client cause many azure client has its default one.
For Azure monitor exporter, looks it can't benefit, cause it only supports instrumentation key and connection string in exporter(limitation of go sdk for appinsights).

[celian-garcia]

Hello, for Azure monitor receiver I think we could benefit yeah. I don't even know what connection string is actually 😄, is it a good sign?
TLDR; yeah cool!!

All our clients are using an azcore.TokenCredential parameter that is generated from the 4 ways you mentioned.
I think the following method summarizes it pretty well:

opentelemetry-collector-contrib/receiver/azuremonitorreceiver/scraper.go

Lines 165 to 193 in 9176dfe

	func (s *azureScraper) loadCredentials() (err error) {
	switch s.cfg.Authentication {
	case defaultCredentials:
	if s.cred, err = s.azDefaultCredentialsFunc(nil); err != nil {
	return err
	}
	case servicePrincipal:
	if s.cred, err = s.azIDCredentialsFunc(s.cfg.TenantID, s.cfg.ClientID, s.cfg.ClientSecret, nil); err != nil {
	return err
	}
	case workloadIdentity:
	if s.cred, err = s.azIDWorkloadFunc(nil); err != nil {
	return err
	}
	case managedIdentity:
	var options *azidentity.ManagedIdentityCredentialOptions
	if s.cfg.ClientID != "" {
	options = &azidentity.ManagedIdentityCredentialOptions{
	ID: azidentity.ClientID(s.cfg.ClientID),
	}
	}
	if s.cred, err = s.azManagedIdentityFunc(options); err != nil {
	return err
	}
	default:
	return fmt.Errorf("unknown authentication %v", s.cfg.Authentication)
	}
	return nil
	}

And exactly like @hgaol, we're using the Azure SDK go client that manages actually the part that generate the token. (so we don't need scope parameter)

All in all, it'd "only" replace the method shown to generate the azcore.TokenCredential, which would already be very nice!

[constanca-m]

Thank you for the suggestions @hgaol @celian-garcia !

For Azure monitor exporter, looks it can't benefit, cause it only supports instrumentation key and connection string in exporter(limitation of go sdk for appinsights).

I expect it to be a way that we can send data directly to the azure monitor endpoint and authorize such requests with the token. The client inside Telemetry configuration is just an http client. So we could overwrite that client with a roundtripper that writes the authorization header with the new token. This way, I don't think the instrumentation key would be necessary. I don't know for sure, because I have not tested it myself, but from reading the source code that's what I expect.

[constanca-m]

Here is the first PR: #38991.