config: add restricted PSS contexts for suggestions

[danish9039]

What this PR does / why we need it:

This PR makes the built-in Katib suggestion deployments compatible with Kubernetes restricted Pod Security Standards by using existing runtime.suggestions[*].securityContext support in the install configs.

It also enables init.controller.injectSecurityContext so Katib metrics collector init containers get restricted-compatible security contexts. No API/schema fields or Trial template mutation are added.

OpenShift install note: katib-openshift keeps the restricted fields but omits a fixed runAsUser so OpenShift SCC UID allocation can choose the namespace-assigned UID.

Validation:

• KUBEBUILDER_ASSETS="$(/home/danish/go/bin/setup-envtest use 1.34.0 -p path)" go test -count=1 ./pkg/util/v1beta1/katibconfig ./pkg/controller.v1beta1/suggestion/composer
• kustomize build for all six install overlays plus katib-with-kubeflow
• git diff --check

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Related to kubeflow/community-distribution#3487

Checklist:

• Docs included if any changes are user facing

[github-actions]

🎉 Welcome to the Kubeflow Katib repo! 🎉

Thanks for opening your first PR! We're excited to have you onboard 🚀

Next steps:

• Our team will review your PR soon! cc @kubeflow/wg-automl-leads
• Check out the Contributing Guide and the Kubeflow Contributor Guide
• Join the Kubeflow Slack channels: https://www.kubeflow.org/docs/about/community/#kubeflow-slack-channels
• Join the AutoML & Training WG meetings: https://bit.ly/2PWVCkV

Feel free to ask questions in the comments. Thanks again for contributing! 🙏

[google-oss-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign johnugeorge for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[coveralls]

Coverage is 9.93% — danish9039:pr3487/katib-restricted-pss into kubeflow:master. No base build found for kubeflow:master.

[danish9039]

Two notes from testing this alongside the downstream restricted Pod Security Standards work in kubeflow/community-distribution#3487.

• The red e2e checks here are not caused by this change. The same jobs fail on unrelated dependabot pull requests that touch only pkg/ui/v1beta1/frontend JavaScript dependencies and cannot affect suggestion runtimes — chore(deps): bump postcss and @angular-devkit/build-angular in /pkg/ui/v1beta1/frontend #2702 fails v1.31.3, v1.33.1 and v1.34.0; chore(deps): bump qs, body-parser, express, @kubernetes/client-node and cypress in /pkg/ui/v1beta1/frontend #2697 fails all four; chore(deps): bump socket.io-parser from 4.2.4 to 4.2.7 in /pkg/ui/v1beta1/frontend #2700 fails v1.34.0. Worth treating as pre-existing rather than a regression in this pull request.
• The katib-openshift variant correctly omits runAsUser while the other installs set 1000. That is the right split: on OpenShift the security context constraint assigns a UID from the namespace range, so a hard-coded 1000 would be rejected, whereas on plain Kubernetes the kubelet needs a numeric identity to satisfy runAsNonRoot: true.

On the fixed runAsUser: 1000 in the non-OpenShift installs: it works today, but only because the images have no OCI User and therefore run as root unless told otherwise. I confirmed every suggestion image plus earlystopping-medianstop and file-metrics-collector declares an empty User. Their Dockerfiles already end with chgrp -R 0 ${TARGET_DIR} && chmod -R g+rwX ${TARGET_DIR}, the arbitrary-UID pattern — and that pattern only works because runAsUser without runAsGroup yields GID 0, which I verified on a restricted-enforcing cluster (uid=1000 gid=0(root) groups=0(root)).

The durable fix would be a numeric USER 1000:0 in the images themselves. The group-0 groundwork is already there, so it is a one-line addition per Dockerfile, and it would let every manifest drop runAsUser — matching what kserve/kserve#5855 and the merged kubeflow/notebooks#1229 do. Restricted only requires runAsNonRoot: true; runAsUser is not part of the profile. Happy to raise that as a follow-up if it is useful.

One thing I could not verify and that is worth a second look: whether all writable paths work under the selected identity for the pbt suggestion specifically, since it mounts a ReadWriteMany persistentVolumeClaim. Unlike emptyDir, PVC ownership is not automatically world-writable, so that path may need fsGroup.

[danish9039]

/retest