search

open-telemetry / opentelemetry-operator

Kubernetes Operator for OpenTelemetry Collector
Apache License 2.0
1.17k stars 414 forks source link

Don't require `cp` in instrumentation images #3231

Open breedx-splk opened 3 weeks ago

breedx-splk commented 3 weeks ago

Component(s)

auto-instrumentation

Describe the issue you're reporting

The javaagent.go (link) component is doing an injection step that runs the cp command at least once, but perhaps several times, from inside the container. This strongly implies that the cp command is available in the container, which prevents distributions from publishing scratch images containing only the agent jar file (and/or extensions). As a result, java agent distributions are required to use FROM busybox or another (linux) distribution, which brings a set of binaries.

This unnecessarily exposes java agent images to vulnerabilities for which the java agent isn't directly related related. This may also make windows compatibility more challenging if cp is required.

I don't know kubernetes operators well enough right now to suggest how this might be addressed, but would appreciate it if we can give this some consideration. Thanks!

pavolloffay commented 3 weeks ago

There has been asks for this in the past in https://github.com/open-telemetry/opentelemetry-operator/issues/1600 due to licensing and CVEs.

One of the solutions was to implement a custom cp utility https://github.com/open-telemetry/opentelemetry-operator/pull/1698 and https://github.com/open-telemetry/opentelemetry-operator/pull/1727

swiatekm commented 3 weeks ago

We need the instrumentation container to be able to copy the agent JAR to a shared volume, from which the application can read it. Busybox cp is the simplest way of achieving that, but it can be any vaguely compatible binary. From my perspective, the primary requirement is that we'd rather not maintain this ourselves.