Specify the workspace Pods securityContext (`SETGID` and `SETUID`) when developers have container build capabilities

Is your enhancement related to a problem? Please describe

Even if the container build is enabled in the CheCluster CR, the required build capabilities (SETUID, SETGID and “allowPrivilegeEscalation”: true) are not explicitly requested in the workspaces Pod SecurityContext.

This is not an issue if the container-build SCC is the only SCC of the workspaces service accounts.

But, if the workspace ServiceAccount is associated with multiple SCCs, the capabilities of the SCC that requires less privileges are picked. And the developer container won’t have SETUID and SETGID capabilities and trying to run a container build will fail.

Describe the solution you’d like

The DevWorkspace Operator provides a way to specify Pods security context using a DevWorkspaceOperatorConfiguration (DWOC) CR. When the build capabilities are enabled, Che Operator should apply a DWOC with the security context {"securityContext":{"capabilities":{"add": ["SETGID", "SETUID"]}, "allowPrivilegeEscalation": true}}).

Additional context

This was initially considered a DWO issue (devfile/devworkspace-operator#884) but the DWO already exposes a mechanism to specify Pods SecurityContext (with the DWOC) so that issue has been closed.

The corresponding OpenShift Dev Spaces issue.

In the future we may allow administrators to specify a custom security context in the CheCluster:

spec:
  devEnvironments:
    podsSecurityContext: {"capabilities":{"add": ["SETGID", "SETUID"]}, "allowPrivilegeEscalation": true}

but that’s a separate issue.

[amisevsk]

However if I remember correctly podSecurityContext is currently ignored on OpenShift

PR https://github.com/devfile/devworkspace-operator/pull/953 adds the containerSecurityContext config field and also makes DWO take podSecurityContext into account when running on OpenShift 😃

Note another potentially simpler approach, if our specific goal is supporting containerBuildCapability – we don’t yet need to have CheCluster fields for pod/container securityContext:

Step 1

Add CheCluster functionality to provision “known, good” container and pod security context into Che-owned DevWorkspaceOperatorConfig when containerBuildCapability: true. This basically automates what we would have to document in a “enabling container build in Che” docs:

CheCluster:

spec:
  devEnvironments:
    disableContainerBuildCapabilities: false # Enable container build

…causes Che Operator to add fields to DevWorkspaceOperatorConfig:

config:
  workspace:
    # Whatever Che Operator decides is necessary here, maybe even a full config
    containerSecurityContext: {"capabilities":{"add": ["SETGID", "SETUID"]}}
    podSecurityContext: {"allowPrivilegeEscalation": false}

This provides a starting point for enabling container builds by simply toggling one field in CheCluster

Step 2

What Andrew is suggesting – add CheCluster fields to allow further customizing securityContext:

spec:
  devEnvironments:
    disableContainerBuildCapabilities: true/false
    containerSecurityContext: <securityContext>
    podSecurityContext: <podSecurityContext>

Setting containerSecurityContext updates the security contexts propagated to the DWOC and allows for finer-grained configuration in situations where it’s necessary, but 90%+ of users ideally don’t need to set these fields.

[amisevsk]

The attribute is required, as it instructs DWO to grant the workspace’s serviceaccount permissions to use the SCC; otherwise pod creation will fail.