Open tasansga opened 4 months ago
You can configure e.g. the namespace that your test pods run in, for different jobs.
Changing this in prow will break assumptions on various places, I don't think we should make prow more complicated for this niche use-case.
You could teach the scanner to ignore based on the job name label or namespace, which shouldn't be any more or less secure than ignoring based on container name. Ignoring based on container name if anything seems much worse than ignoring a certain namespace (much more likely that you have security rules controlling who can use what namespace than who can use what container names).
The cluster in question is a SaaS product. The third-party vulnerability scanner is mandatory and not configurable by me. Also the scanner's service provider will not implement a namespace-based exclude feature for it.
What places are you aware of where this would break assumptions?
The cluster in question is a SaaS product. The third-party vulnerability scanner is mandatory and not configurable by me. Also the scanner's service provider will not implement a namespace-based exclude feature for it.
IMHO it is very surprising and questionable to have a container name based exclude instead of a namespace based exclude and this is not something the Kubernetes project's CI should go out of our way to support.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The third-party vulnerability scanner in our cluster runs checks based on the container names in the pods. It regularly triggers on some of our periodic Prow jobs that, in turn, we'd like to exclude from the default scan, while still allowing other Prow jobs to be scanned in full.
However, Prow hard-codes the container name to
test
, so it's currently not possible for the vulnerability scanner to distinguish between Prow jobs.Please add a feature that makes the Prow test container name configurable on the Prow job level.