You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Detect (and meanwhile flag) images in common custom resources with PodSpecs #75
kir extracts images from a fixed set of core workload kinds (Pod, Deployment, DaemonSet, ReplicaSet, StatefulSet, Job, CronJob). Any document whose kind isn't registered in the scheme — CRDs / custom resources — is skipped (see #54). But many widely-used custom resources embed a pod template or image references, so kir silently misses their images today. For a tool that feeds vulnerability scanners, that's a coverage gap — and the same silent-data-loss class as #49.
This issue tracks two things: a short-term visibility improvement, and the longer-term detection work with a concrete catalog of targets.
(a) Visibility now: flag unrecognized kinds ("seen but not detected")
Today an unregistered kind is skipped silently. As a stepping stone — and independent of how detection is eventually implemented — kir can warn on stderr (exit 0) when it meets a kind it doesn't understand:
warning: skipped unrecognized kind "Rollout" (argoproj.io/v1alpha1); kir cannot yet extract images from it
This tells users kirsaw the document but didn't inspect it, instead of leaving them to guess whether images were missed. stdout stays clean (images only), so pipelines are unaffected; exit stays 0 because an unknown kind isn't a failure. Contrast with known image-less kinds (Service, ConfigMap), which stay silently skipped — they're expected and have nothing to report. See the document-classification policy documented in #54.
(b) Detection: support common custom resources
The mechanism is tracked in #26 (dynamically locate a PodSpec rather than hardcoding kinds; Cue explored in #27–#30). Whichever approach wins, this is the concrete target list — each row is also a good acceptance fixture:
Resource
API group · kind
Where the images live
Argo Rollouts
argoproj.io · Rollout
spec.template (a PodTemplateSpec, like Deployment)
spec.image, plus spec.containers[] / initContainers[]
KubeVirt
kubevirt.io · VirtualMachine(Instance)
spec.template.spec.volumes[].containerDisk.image — a different shape, likely out of scope for a PodSpec-based detector
Not every custom resource fits a PodSpec: some carry bare image: fields, and some (Flux, cert-manager) carry none. A PodSpec-only detector covers the majority; the odd ones out are candidates for explicit per-kind handling — or explicit non-support.
Suggested rollout
Land visibility (a) first — small, and immediately useful on its own.
Summary
kirextracts images from a fixed set of core workload kinds (Pod,Deployment,DaemonSet,ReplicaSet,StatefulSet,Job,CronJob). Any document whose kind isn't registered in the scheme — CRDs / custom resources — is skipped (see #54). But many widely-used custom resources embed a pod template or image references, sokirsilently misses their images today. For a tool that feeds vulnerability scanners, that's a coverage gap — and the same silent-data-loss class as #49.This issue tracks two things: a short-term visibility improvement, and the longer-term detection work with a concrete catalog of targets.
(a) Visibility now: flag unrecognized kinds ("seen but not detected")
Today an unregistered kind is skipped silently. As a stepping stone — and independent of how detection is eventually implemented —
kircan warn on stderr (exit 0) when it meets a kind it doesn't understand:This tells users
kirsaw the document but didn't inspect it, instead of leaving them to guess whether images were missed.stdoutstays clean (images only), so pipelines are unaffected; exit stays0because an unknown kind isn't a failure. Contrast with known image-less kinds (Service,ConfigMap), which stay silently skipped — they're expected and have nothing to report. See the document-classification policy documented in #54.(b) Detection: support common custom resources
The mechanism is tracked in #26 (dynamically locate a
PodSpecrather than hardcoding kinds; Cue explored in #27–#30). Whichever approach wins, this is the concrete target list — each row is also a good acceptance fixture:argoproj.io·Rolloutspec.template(a PodTemplateSpec, like Deployment)argoproj.io·Workflow,CronWorkflowspec.templates[].container/.script.image,.containerSet.containers[]serving.knative.dev·Service,Configuration,Revisionspec.template.spec.containers[]tekton.dev·Task,TaskRun,Pipeline…spec.steps[].image,spec.sidecars[].imageapps.kruise.io·CloneSet, AdvancedStatefulSet/DaemonSet,BroadcastJobspec.template.spec)keda.sh·ScaledJobspec.jobTargetRef.template.spec(pod template).ScaledObjectonly references a workload — no direct imagesmonitoring.coreos.com·Prometheus,Alertmanager,ThanosRulerspec.image, plusspec.containers[]/initContainers[]kubevirt.io·VirtualMachine(Instance)spec.template.spec.volumes[].containerDisk.image— a different shape, likely out of scope for a PodSpec-based detectorNot every custom resource fits a
PodSpec: some carry bareimage:fields, and some (Flux, cert-manager) carry none. A PodSpec-only detector covers the majority; the odd ones out are candidates for explicit per-kind handling — or explicit non-support.Suggested rollout
PodSpecin manifests #26): structural PodSpec search vs. per-kind extractors vs. Cue (Use newest CUE (0.13.x - needed for registry support) #27–Extract images from PodSpec using Cue #30).Notes
PodSpecin manifests #26 (mechanism), Use newest CUE (0.13.x - needed for registry support) #27–Extract images from PodSpec using Cue #30 (Cue exploration), feat: skip non-workload documents instead of aborting the stream #54 (skip + stderr policy), fix: process all documents from stdin, not just the first #49 (silent-drop class).