Add ability to use SCCs in DevWorkspaces on OpenShift

[amisevsk]

What does this PR do?

This is a proof-of-concept PR that adds the ability to use SecurityContextConstraints (SCCs) in DevWorkspaces, which can be used to e.g. enable container builds within workspace containers. SCCs used by a DevWorkspace are defined through the attribute controller.devfile.io/scc: <scc-name>.

In order to avoid overextending the default DWO RBAC, no ability to view/edit SCCs is granted to the Operator by default, and attempting to use SCCs in workspaces will fail with a message like

operator does not have permissions to get the 'anyuid' SecurityContextConstraints

The requirements to use this feature are:

1. The DevWorkspace Operator serviceaccount must explicitly be granted get and update privileges for a given SCC by a cluster-admin
2. The user creating the DevWorkspace must be granted the use privilege on that SCC by a cluster-admin
3. The DevWorkspace must be created with the controller.devfile.io/scc attribute by a user with permissions to use that SCC.

One benefit in this approach is that the cluster admin can revoke these privileges from users/the controller after the fact without breaking regular workspaces.

Once the controller.devfile.io/scc attribute is set on a DevWorkspace, it cannot be modified in order to avoid leaking SAs into existin SCCs. Using the attribute adds a finalizer for SCCs to the DevWorkspace to ensure any changes to SCCs are cleaned up when the workspace is deleted.

Since SCCs are an OpenShift feature, this functionality is disabled on Kubernetes and attempting to use the attribute will be rejected by webhooks.

What issues does this PR fix or reference?

Closes eclipse-che/che#20459

Is it tested? How?

The steps below follow similarly to the Buildah OpenShift rootless build doc.

1. Create a new SCC that grants the specific capabilties that are required (any scc can be used but this is probably best practice here):

   cat <<EOF | oc apply -f -
   apiVersion: security.openshift.io/v1
   kind: SecurityContextConstraints
   metadata:
     name: container-build
   allowHostDirVolumePlugin: false
   allowHostIPC: false
   allowHostNetwork: false
   allowHostPID: false
   allowHostPorts: false
   allowPrivilegeEscalation: true
   allowPrivilegedContainer: false
   allowedCapabilities: null
   defaultAddCapabilities: null
   fsGroup:
     type: RunAsAny
   priority: 10
   readOnlyRootFilesystem: false
   requiredDropCapabilities:
   - "KILL"
   - "MKNOD"
   runAsUser:
     type: RunAsAny
   seLinuxContext:
     type: MustRunAs
   supplementalGroups:
     type: RunAsAny
   users: []
   volumes:
   - configMap
   - downwardAPI
   - emptyDir
   - persistentVolumeClaim
   - projected
   - secret
   EOF

   This SCC is a modified version of the anyuid SCC with the added requirement that containers drop the KILL capability.
2. Grant the DevWorkspace Operator the get and update privileges for this SCC:

   NAMESPACE=<namespace-where-dwo-is-deployed>
   
   cat <<EOF | oc apply -f - 
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: dwo-access-to-scc
     labels:
       test: dwo-scc-access
   rules:
   - apiGroups:
       - "security.openshift.io"
     resources:
       - "securitycontextconstraints"
     resourceNames:
       - "container-build"
     verbs:
       - "get"
       - "update"
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: dwo-access-to-scc
     labels:
       test: dwo-scc-access
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: dwo-access-to-scc
   subjects:
   - kind: ServiceAccount
     name: devworkspace-controller-serviceaccount
     namespace: ${NAMESPACE}
   EOF

3. Let the user creating the DevWorkspace use the container-build SCC:

   oc adm policy add-scc-to-user container-build <username>

4. Create a DevWorkspace that uses the container-build SCC:

   cat <<EOF | oc apply -f -
   kind: DevWorkspace
   apiVersion: workspace.devfile.io/v1alpha2
   metadata:
     name: container-build
   spec:
     started: true
     routingClass: 'basic'
     template:
       attributes:
         controller.devfile.io/scc: container-build
         controller.devfile.io/storage-type: ephemeral
       components:
         - name: container-build
           container:
             image: quay.io/amisevsk/container-build:dev
             memoryLimit: 512Mi
             mountSources: true
             command:
             - "tail"
             - "-f"
             - "/dev/null"
   EOF

   The image used in this DevWorkspace is build according to the buildah doc and can be used to run buildah builds.
5. Check that the pod created for this workspace has the openshift.io/scc: container-build annotation
6. Exec into the pod and verify configuration is as specified in the buildah doc (e.g. user is 1000, can build images)
7. Delete DevWorkspace, and verify that .users field in container-build SCC is empty (i.e. that the workspace's ServiceAccount is removed)

PR Checklist

• E2E tests pass (when PR is ready, comment /test v8-devworkspace-operator-e2e, v8-che-happy-path to trigger)
  • v8-devworkspace-operator-e2e: DevWorkspace e2e test
  • v8-che-happy-path: Happy path for verification integration with Che

[JPinkney]

LGTM. I'm definitely a fan of giving cluster admins all the control here

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: amisevsk, JPinkney

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [JPinkney,amisevsk]

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

[amisevsk]

/test v8-devworkspace-operator-e2e

[openshift-ci]

New changes are detected. LGTM label has been removed.

[amisevsk]

/test v8-devworkspace-operator-e2e