Update test-infra for kubernetes-security/kubernetes

[ritazh]

Goals:

• to reduce bugs in CVE patches
• to reduce delays in CVE public disclosure
• to reduce time to patch vulnerabilities

Outcome:

• determine minimum set of tests to run
• determine a set of members who will have access and ownership to maintain this test infrastructure to keep it up-to-date

cc @BenTheElder

[ameukam]

/assign @BenTheElder

/kind feature
/committee security-response
/priority backlog

[BenTheElder]

... also related: #4981

[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

[xmudrii]

/remove-lifecycle stale

[BenTheElder]

Had a few more discussions about this, there's additionally concern that our test environments don't currently have concern of info leak and many of them are barely maintained (e.g. kube-up.sh), we could mitigate that cheaply by simply not using some of them here though.

But if/when we do this, we should be careful about e.g. the e2e test environments as well.
The security on them is ... lax, with the expectation that PR testing is essentially by design RCE on public code.

I'm still concerned about sigs.k8s.io/prow in particular, which basically has one active approver, and would have much higher expectations if it needs to secure a private repo. We need to fix that regardless, but "recruiting" for this work has been ... tough.

I had a new thought for this: We could select a subset of tests and wire them up with github actions as a stopgap?

It will be difficult to guarantee that we definitely get the same results for everything when the patches go public, and that we keep the configs in sync, but it's probably better than doing nothing, and a lot of our testing doesn't require cloud e2e anymore (since we're able to use sigs.k8s.io/kind in particular).

The biggest question is how to coordinate ongoing upkeep, maybe we could form a team that agrees to the embargo restrictions for this purpose? There are a relatively small set of maintainers particularly active on kubernetes/kubernetes PR test configuration (SIG Testing TLs, perhaps a few other folks).

[BenTheElder]

cc @kubernetes/sig-testing-leads @kubernetes/sig-k8s-infra-leads @kubernetes/security-response-committee
/sig testing