Allow renaming Prow's test container for individual jobs

[tasansga]

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.

[BenTheElder]

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).

[tasansga]

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?

[BenTheElder]

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.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale