Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WorkloadIdentity support in AzureDataExplorer exporter #33667

Closed
mipnw opened this issue Jun 20, 2024 · 3 comments · Fixed by #35835
Closed

WorkloadIdentity support in AzureDataExplorer exporter #33667

mipnw opened this issue Jun 20, 2024 · 3 comments · Fixed by #35835
Labels

Comments

@mipnw
Copy link
Contributor

mipnw commented Jun 20, 2024

Component(s)

exporter/azuredataexplorer

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

exporter/azuredataexplorerexporter does not currently have support for Azure WorkloadIdentity.

Applications running on Kubernetes cannot yet securely export to Azure Data Explorer with this exporter. They would have to use a client secret to use this exporter, as opposed to using a managed identity. WorkloadIdentity is basically just another form of managed identity that is specific to Kubernetes. For more information see

Currently if you configure the exporter with managed_identity_id:system you don't get the correct behavior when hosted in Kubernetes, the exporter attempts to pull a token from Azure Instance Metadata Service (i.e. from 169.254.169.254) and there is no such service in Kubernetes, that would only be appropriate on an Azure hosted VM.

Describe the solution you'd like

One solution would be to add a new managed_identity_id=workloadidentity configuration and use Azure Kusto Go's ConnectionStringBuilder.WithKubernetesWorkloadIdentity when that option is present instead of the other connectionstring buildsers currently used to handle managed identities.

Describe alternatives you've considered

n/a

Additional context

I've forked this repository and created a branch with the proposed solution at https://github.com/mipnw/opentelemetry-collector-contrib/tree/feature/azuredataexplorer_workloadidentity

@mipnw mipnw added enhancement New feature or request needs triage New item requiring triage labels Jun 20, 2024
Copy link
Contributor

Pinging code owners:

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

Copy link
Contributor

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

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

@andreidorin-oprea
Copy link
Contributor

@atoulme I see there are 2 PRs that went stale for the same issue. What can I do to move the needle for solving this?

jpbarto pushed a commit to jpbarto/opentelemetry-collector-contrib that referenced this issue Oct 29, 2024
…emetry#35835)

#### Description
Add the ability to use the default Azure SDK authentication for the
kusto client. This enables users to use workload identity.

Links:
-
https://learn.microsoft.com/azure/developer/go/azure-sdk-authentication?tabs=bash#2-authenticate-with-azure
-
https://github.com/Azure/azure-kusto-go/blob/11658efc9faad4d0300afdc4af9a19c470b0313a/azkustodata/kcsb.go#L294C1-L298C2
-
https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview?tabs=go

#### Link to tracking issue
Fixes
open-telemetry#33667

#### Testing
- `make`
- deploy controller in kind cluster using workload identity, send dummy
traces and validate that they reach the ADX cluster

#### Documentation
Split the authentication docs for each mechanism available.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
3 participants