Open evantorrie opened 2 months ago
Pinging code owners:
processor/k8sattributes: @dmitryax @rmfitzpatrick @fatsheep9146 @TylerHelmuth
See Adding Labels via Comments if you do not have permissions to add labels yourself.
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.
Component(s)
processor/k8sattributes
Is your feature request related to a problem? Please describe.
We currently make use of the
k8sattributes
processor to augment Resource attributes from pods running in our k8s clusters.We are interested in obtaining a useable repo digest version of the image (i.e. something that references an immutable fetchable image from a repository) associated with the container in a Kubernetes pod that is emitting telemetry, rather than relying on just the image name + tag.
One use of this is to be able to identify vulnerable containers which are still emitting telemetry in our fleet. Relying purely on mutable tag references (e.g.:latest) results in false positives when a vulnerability has been addressed and a new "latest" version of the image has been pushed. Yet vulnerable versions may still remain remaining, even though they still reference
<image>:latest
in their PodSpec.Describe the solution you'd like
If we include
container.image.repo_digests
in thek8sattributes::metadata
array, we'd like to get not onlycontainer.image.name
,container.image.tag
, but alsocontainer.image.repo_digests
added to the resource for that signal.Describe alternatives you've considered
Scrape information from kube-state-metrics (which does provide the image digest) and somehow cross-join that with the resource attributes determined by k8sattributes processor?
Additional context
This issue was initially opened in #32152 thinking that the correct attribute to populate would be
container.image.id
using the k8sImageID
field. However, after more diligence in the now closed PR #32314, it was observed that Kubernetes doesn't provide a solid guarantee that its k8s APIimageID
field will always have a fetchable repository digest reference. In some cases, it may just be a digest lacking a repository image reference.This new issue is intended to address this deficiency by recommending we populate the alternative
container.image.repo_digests
field if and only if the reference returned in the k8s API is a "Canonical" reference as defined by the code in github.com/distribution/reference.