Suppress warning about 0.0.0.0

[yurishkuro]

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

Using the 0.0.0.0 address exposes this server to every network interface, 
which may facilitate Denial of Service attacks.

When running inside a container, binaries are expected to listen to 0.0.0.0, because they don't know any other IP and localhost makes them inaccessible in many scenarios.

Describe the solution you'd like

I don't want this warning to appear when the 0.0.0.0 configuration is actually valid and expected.

I propose adding some environment variable that can be set in the Dockerfile that will instruct the Collector not to log this warning.

Describe alternatives you've considered

To my knowledge there is no reliable way to determine if a binary is running inside a container.

Related issues

• DOS warning about binding to 0.0.0.0 does not apply to serverless environments #9753
• Why is 0.0.0.0 the default host? #8510

[mx-psi]

Based on #8510 (comment) we should remove the warning. Do you want to file a PR for this?

[yurishkuro]

I am not opposed to the warning when it is actually relevant. For example, Jaeger all-in-one comes with a built-in configuration (not provided by user) and we have to hardcode 0.0.0.0 IP there to make it work in containers. But if the raw binary is run and also listens on 0.0.0.0 then it's back to the same CVE, so a warning to the user is good. Not to mention in situations where IP is actually provided by the user and they make a mistake which makes them insecure.

[mx-psi]

The warning will remain in our security documentation, but based on the vote we did it should be removed. I think regardless, it is quite difficult to reliably figure out if you are running inside a container or not, so I am not sure how we would go about this if we wanted to keep the warning

[yurishkuro]

That's why I am proposing a well-defined env var like OTEL_IN_CONTAINER that can be used. We could even let the collector use this in place of the former feature flag to allow it to automatically decide which IP is the most appropriate to use, so that when a user just says "I want grpc receiver" they don't need to fiddle with the endpoint, collector will do the right thing.