Add oauth2clientauthextension #1492
Comments
|
@svrnm thanks for raising this request. It is indeed something we are hearing more often and consider this in a wider context. |
|
thanks @mhausenblas! |
|
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days. |
|
This issue was closed because it has been marked as stale for 30 days with no activity. |
|
We use AppDynamics and AWS extensively and are waiting to use ADOT however are blocked by the missing OAuth functionality. |
|
Is there an update on a timeline when oAuth will be supported with ADOT? |
|
@noMoreCLI not yet, please sync up with @svrnm |
|
Any update on this? |
|
@eriweb it's on our backlog, when we're getting closer to it I will provide some more guidance but for now, our thinking is to provide a comprehensive solution that may include also the Basic Authenticator. I would love to learn about your use case/requirements if you can share? |
|
@mhausenblas it is to send metrics/tracing to 3rd party solutions. We're currently trying to integrate with AppDynamics to get a combined view of AWS as well as on-prem solutions. |
|
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days. |
|
Can this issue be marked to not stale at all? There is still demand for it :-) |
|
@mhausenblas Interestingly enough I found this thread because I as working on a metrics pipeline that consumes AppD Cloud, and AWS Prometheus. I have a sneaking suspicion the |
|
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days. |
|
This is still needed. |
|
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days. |
|
This is still needed, please un-stale |
|
Bump! |
|
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days. |
|
This issue was closed because it has been marked as stale for 30 days with no activity. |
|
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days. |
github-project-automation
bot
moved this to Requested
in Public Roadmap: AWS Distro for OpenTelemetry (ADOT)
|
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days. |
**Problem:** 1. An Opentelemetry collector needs to be deployed to ECS to support forwarding telemetry data for long-term storage and analysis. 2. A configuration file for the collector needs to be sourced from AWS secrets manager and injected into the Otel collector to configure the service. 3. Environment variables need to be updated in the schematic container to support configuring it to send telemetry data to the Otel collector. 4. A container level health check is needed as this service is not fronted by a load balancer. **Solution:** 1. Deploying the otel collector contributor container to ECS. I had attempted to use the AWS otel collector, however, they do not support the Oauth2 extension that we will use to attached an Auth header on out-going requests: aws-observability/aws-otel-collector#1492 2. Storing the otel config file in AWS Secret manager and injecting it into the Otel collector by overriding the docker CMD command on the container. 3. Setting environment variables on the schematic container to configure it sending telemetry data to the otel collector. 4. Pointing to our sage specific docker image that contains a binary compiled from golang that does container level health checks. **Testing:** 1. I verified that I was able to deploy both schematic and the otel collector to AWS ECS. 2. I verified that by setting the environment variables in schematic that it was able to produce, and forward it's data to the otel collector. 3. I verified that the otel collector was able to perform the oauth2 client credential exchange with Auth0 to obtain an access token. 4. I verified that both logs AND traces were forwarded to the kubernetes cluster/SigNoz and ingested into Clickhouse for long-term storage. 5. I verified that the telemetry data showed up in the SigNoz UI as expected.
|
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days. |
Is your feature request related to a problem? Please describe.
The AppDynamics Cloud backend authenticates opentelemetry ingestion via oauth, for that we leverage the oauth2clientauthextension. For end-users who want to send telemetry from ADOT collector to our backend we have to ask them to put another collector in between.
Describe the solution you'd like
Describe alternatives you've considered
We can ask customers to send data from adot collector to appd collector
Additional Context
I assume that we are not the only ones leveraging oauth2, so this is beneficial to other observability backends as well.
cc @liamoddell, @pavankrish123
The text was updated successfully, but these errors were encountered: