Support components of type Kubernetes and OpenShift

[amisevsk]

Description

The Devfile API specifies Kubernetes and OpenShift component types, which consist mainly of raw Kubernetes/OpenShift yaml/json objects that should be applied to the cluster. These components are currently ignored by the DevWorkspace Operator, but should be supported -- at least at a "best effort" level (i.e. within DWO privileges and with limited syncing/cleanup)

Additional context

Related to eclipse-che/che#17894

[Bolodya1997]

@amisevsk
Hello, is there any plan or progress for this issue?
It looks like this can be used to combine secrets automount and providing secrets via devfile:

components:
  - name: git-credentials-gitlab
    kubernetes:
      inlined: |
        {
          "kind": "Secret",
          "apiVersion": "v1",
          "metadata": {
            "name": "git-credentials-gitlab",
            "annotations": {
              "controller.devfile.io/mount-path": "/home/theia/.git-credentials"
            },
            "labels": {
              "controller.devfile.io/git-credential": "true",
              "controller.devfile.io/watch-secret": "true"
            }
          },
          "type": "Opaque",
          "data": {
            "credentials": "aHR0cDovL...b2NhbA=="
          }
        }

Currently it doesn't look like there is a way to propagate secrets to the user namespace in a more or less automatic way without having admin access, so it will be extremely helpful if this would be implemented.

[amisevsk]

@Bolodya1997 There's no progress to report here yet, but it's in our backlog for the semi-near future -- there have just been other more pressing issues/features in the mean time.

One note about your suggestion

Currently it doesn't look like there is a way to propagate secrets to the user namespace in a more or less automatic way without having admin access, so it will be extremely helpful if this would be implemented.

I'm 90% sure the ultimate implementation here will use RBAC for the user creating the DevWorkspace to ensure they have permissions to create/update the objects in the kubernetes component. As a result, using this field to create secrets in a namespace where you cannot create those secrets directly likely will not work. This would be to avoid privilege escalation. I would generally advise against storing secret data in the DevWorkspace definition, as there's not much effort to not make it readable (e.g. it is mounted as files inside any DevWorkspace container).

[Bolodya1997]

@amisevsk Thank you for your response! This note is quite helpful for me.

[kernelpanic77]

@amisevsk, I am currently working on the implementation of the compose component. To convert compose-spec files to kubernetes manifests, we will be using kompose. Earlier kompose used to provide support for managing kubernetes resources using kompose up and kompose down services, however these are now depreciated. kubernetes/kompose#1275.

Since, kompose is only responsible for generating manifest with kompose convert, I think it would be better to implement support for kubernetes components first, before implementing the compose component.

[amisevsk]

Is kompose usable as a library? DWO will not be able to use the CLI itself for this purpose.