Support running a workspace in kata containers

[l0rd]

Is your enhancement related to a problem? Please describe

Kata containers allow running pod in dedicated VMs. That makes it possible to run a container as root without any security exposure (and run apt-get/yum install or buildah).

To run a Che workspace in a kata container the workspace Pod should specify runtimeClassName: kata:

apiVersion: v1
kind: Pod
metadata:
  ...
spec:
  runtimeClassName: kata
  containers:
  ...

But that's not currently possible.

Describe the solution you'd like

To implement we should:

1. Add spec.runtimeClassName field in DevWorkspace CRD that, if set and if the user has the necessary privileges, will be propagated to all the workspace Pods.
2. Add a new Che URL parameter runtime-class-name: https://<che-host>#<repository_url>?<runtimeClassName>. If set the resulting DevWorkspace should include the runtimeClassName

Additional context

Here I have described how to setup an OpenShift cluster with kata containers and run buildah in it.

[amisevsk]

We can support this via an attribute in the DevWorkspace Operator, or by adding the relevant field to the DevWorkspace CRD -- which is preferable here?

It would be very straightforward to define e.g. controller.devfile.io/runtimeClassName as an attribute and propagate that to the pod created for that workspace. This also has the benefit of not adding more explicit fields to the DevWorkspace API and also being "upgradeable" to an explicit CRD field in the future.

[l0rd]

We can support this via an attribute in the DevWorkspace Operator, or by adding the relevant field to the DevWorkspace CRD -- which is preferable here?

I want to let the developers to choose if the workspace will run in a Kata container or not. In other words, on the same OpenShift cluster, a developer can:

• specify the factory URL parameter runtime-class-name=kata and the workspace will be started using kata containers
• omit the factory URL parameter runtime-class-name and the workspace will be started using a regular Pod.

So if the attribute your are thinking about is at the DevWorkspace CR level than 👍

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

[amisevsk]

/remove-lifecycle stale

[l0rd]

This is now possible using devfile attributes as describe in the PR