-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Enable retrieving container.image.repo_digests
attribute in k8sattributes processor
#34029
Comments
Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
**Description:** Adds support for extracting canonical repo digest image references for a container from k8s attributes **Link to tracking Issue:** #34029 **Testing:** 1. Adds unit tests for extracting the k8s `.imageID` field from container status API if it is of the `reference.Canonical` form, and storing it in a `ImageRepoDigest` string field. (Note: k8s will only ever return one value here, although the semantic conventions for `container.image.repo_digests` define it to be a `Slice`. We convert into a Slice lazily when we populate the pcommon data structure. 2. Adds unit tests for including `container.image.repo_digests` in rules for extraction. 3. Includes `container.image.repo_digests` in the e2e tests for k8sattributes processor. **Documentation:** Added `container.image.repo_digests` as an example of attributes that can be extracted from a container --------- Co-authored-by: Christos Markou <[email protected]>
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 Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
Closing as resolved. |
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.The text was updated successfully, but these errors were encountered: