Add a prohibit-kubernetes-plugin option, usable as either a flag or config option, which causes jobs to fail if they contain plugins: - kubernetes: ....
Why
This is an easy way to lock down a k8s cluster and prevent users from doing such things as:
using podSpec or podSpecPatch to specify undesirable container images, override the container entrypoint, etc
using extraVolumeMounts to mount undesirable volumes
using env, envFrom, or gitEnvFrom to map and leak unintended secrets
disabling or enabling the checkout container, override git flags in an undesirable way,
etc etc
How
The main change is to introduce the prohibit-kubernetes-plugin flag and config value, and then use it throughout the scheduler.
Because this balances things out of favour of a k8sPlugin-centric interpretation of celestial mechanics, some useful refactors were in order:
Build now takes a pointer to the podSpec it is supposed to be building, so that we can change which one we're building from Create. BuildFailureJob doesn't have to set k8sPlugin.PodSpec in order to build a special podspec.
Labels and annotations are set on kjob first, instead of set in k8sPlugin and then moved to kjob.
jobWrapper is now buildInputs. It has no methods (they're moved to worker) and is intended to contain only the relevant parts of CommandJob needed by Build or BuildFailureJob. The goal is to make the data flow (what data is need by which operation) clearer.
What
Add a
prohibit-kubernetes-pluginoption, usable as either a flag or config option, which causes jobs to fail if they containplugins: - kubernetes: ....Why
This is an easy way to lock down a k8s cluster and prevent users from doing such things as:
etc etc
How
The main change is to introduce the
prohibit-kubernetes-pluginflag and config value, and then use it throughout the scheduler.Because this balances things out of favour of a
k8sPlugin-centric interpretation of celestial mechanics, some useful refactors were in order:Buildnow takes a pointer to the podSpec it is supposed to be building, so that we can change which one we're building fromCreate.BuildFailureJobdoesn't have to setk8sPlugin.PodSpecin order to build a special podspec.kjobfirst, instead of set ink8sPluginand then moved tokjob.jobWrapperis nowbuildInputs. It has no methods (they're moved toworker) and is intended to contain only the relevant parts ofCommandJobneeded byBuildorBuildFailureJob. The goal is to make the data flow (what data is need by which operation) clearer.