Define SecurityContext for container components

[kadel]

With the introduction of Pod Security Admission in Kubernetes 1.25 and with OpenShift enabling this by default in 4.11 (https://cloud.redhat.com/blog/pod-security-admission-in-openshift-4.11)

Devfile should allow users to define SecurityContext for container components.

The SecurityContext is required to pass the checks performed by PodSecurity Admission controller.
For example, in OCP 4.11 the "restricted" policy is audited. That means that every container started without proper SecurityContext will be recorded will produce a warning and will be recorded to the audit log.
The containers without proper SecurityContext will be even more problematic with future OCP versions as they plan to change the default from "audit" to "enforce". This will mean that every container that doesn't meet the "restricted" requirements will be rejected.

[kadel]

There are two solutions for this.
We either allow users to define SecurityContext as part of the devfile container definition.

Or we leave the responsibility of correctly setting the SecurityContext to tooling.
The tooling approach might not work as I'm not sure if tools will be able to always correctly determine the correct SecurityContext setting for each cluster.

[Jdubrick]

Closing issue as I believe users can define SecurityContext in the latest devfile schema version. If this is incorrect we can reopen it.

[michael-valdron]

Closing issue as I believe users can define SecurityContext in the latest devfile schema version. If this is incorrect we can reopen it.

You can by overriding through the attributes: https://devfile.io/docs/2.2.2/overriding-pod-and-container-attributes#container-overrides

But the schema spec does not contain SecurityContext field properties for components. With container and pod overriding attributes, I don't think this is a priority to implement.