When the disableContainerBuildCapabilities parameter is set to true, RoleBindings for Service Accounts are not created about che

[tolusha]

Hello @dmitryrode

I see.
Removing the check [1] should allow to configure default container security context along with custom scc.
The reason, why it has been done in that way is [2]
The author @AObuchow is on PTO know. Once he is available, I will contact him.
But personally, I don't see any problem with removing that if clause.

[1] https://github.com/eclipse-che/che-operator/blob/a4e19ead9d324dce09f5ca400a5cb7eff3abd253/pkg/deploy/dev-workspace-config/dev_workspace_config.go#L125
[2] #22307

The workaround is to update the default container security context.
So, please update Eclipse Che subscription in this way:

  config:
    env:
      - name: CHE_DEFAULT_SPEC_DEVENVIRONMENTS_CONTAINERSECURITYCONTEXT
        value: '<JSON_STRING_REPRESENTING_CONTAINER_SECURITY_CONTEXT>'

For instance:

  config:
    env:
      - name: CHE_DEFAULT_SPEC_DEVENVIRONMENTS_CONTAINERSECURITYCONTEXT
        value: '{"allowPrivilegeEscalation": true,"capabilities": {"add": ["SETGID", "SETUID"]}}'

[tolusha]

Hello.
This is expected, that when disableContainerBuildCapabilities: true [1] then roleBinding is not created.
So, please use disableContainerBuildCapabilities: false.

[1] https://github.com/eclipse-che/che-operator/blob/a4e19ead9d324dce09f5ca400a5cb7eff3abd253/pkg/deploy/container-build/container_build.go#L44

[dmitryrode]

Hi @tolusha, thank you sincerely for your response; your insights are immensely valuable to me.

Regarding the disableContainerBuildCapabilities parameter, it indeed appears prudent to set it to false to ensure the creation of the Service Account (SA). However, I'm curious about the functionality of custom containerSecurityContext. My understanding is that without specific bindings for the Service Account (SA), it might be challenging to implement a more tailored Security Context. From the docs

Disables the container build capabilities. When set to false (the default value), the devEnvironments.security.containerSecurityContext field is ignored, and the following container SecurityContext is applied: \n containerSecurityContext: allowPrivilegeEscalation: true capabilities: add: - SETGID - SETUID

Could you please shed more light on this? Don't you think there's room for improvement here?

[tolusha]

Hello @dmitryrode

If you need to use the custom SCC, then:

1. Create a custom SecurityContextConstraints object.
2. Set the name of the SecurityContextConstraints object into CheCluster CR.

With regards to the disableContainerBuildCapabilities field.
It seems the description confuses.
Correction:

When set to **true**, the the devEnvironments.security.containerSecurityContext field is ignored ...

[tolusha]

To be honest I don't like this snippet, for me it looks inconsistent [1]
@AObuchow Could you have a look please? Do we really want to set default security context when build capabilities are enabled?

https://github.com/eclipse-che/che-operator/blob/a4e19ead9d324dce09f5ca400a5cb7eff3abd253/pkg/deploy/dev-workspace-config/dev_workspace_config.go#L123-L140

[dmitryrode]

Hello @tolusha, thank you for sharing the details. I attempted to adjust the parameters, but integrating them with OpenShift appears somewhat convoluted. But I can confirm custom SCC works fine :) But only whendisableContainerBuildCapabilities = true.

Let me elaborate further details:

1. Initially, I created a new custom SCC to grant Service Accounts (SA) more relaxed capabilities than the defaults.
2. Consequently, upon creating workspaces, everything appeared to function smoothly. However, this was only with the default containerSecurityContext in workspace Deployments, limited to SETGID and SETUID permissions [1].
3. Yet, imho it seems redundant to establish a custom SCC without providing corresponding modifications to the Container Security Context, such as capabilities adjustments or SELinux tweaks. In this case I need provide my capabilities and SELinux and disable default build capabilities. Then go to the 4th point.
4. Enabling custom Container Security Context necessitates setting disableContainerBuildCapabilities = true.
5. After the point 4th, SA creation performed without RBAC (RoleBinding to the Role allowing usage of securityContextConstraints).

Does it genuinely make sense to proceed in this manner in case of using custom Security Contexts?

I believe you are right and the snippet from the comment above looks inconsistent :) Otherwise it turns out that we are losing the ability to manage SCC and Container Security in such configurations.

[1] https://github.com/eclipse-che/che-operator/blob/main/pkg/deploy/container-build/container_build.go#L273

[dmitryrode]

@tolusha, I mean the following:

the former pathway appears functional:

Custom OpenShiftSecurityContextConstraint → Workspace Creation → Automatic SA Generation → Automatic RBAC Establishment (RoleBinding with permissions to utilize your SCC) → Workspace Execution.

However, the pathway involving container security context encounters issues:

Custom OpenShiftSecurityContextConstraint → Custom ContainerSecurityContext → Workspace Creation → Automatic SA Generation → Absence of RBAC Setup → Workspace Failure due to SA inability to utilize the custom OpenShift SCC.

[dmitryrode]

Hello @tolusha, thank you very much for the provided insights. I'll be sure to give the proposed workaround a try.

Looking forward to hearing @AObuchow's feedback as well.

[AObuchow]

@dmitryrode @tolusha IIRC, we don't allow modifying the containerSecurityContext when container builds are enabled, as a way to ensure the correct container-build SCC is selected to permit building containers in a workspace. If a workspace service account has multiple SCCs available, a suitable SCC that has the least amount of privileges is picked. See the original issue description.

In other words, we intended to always have the container security context set to the following to ensure the provided container builds SCC would work:

	  containerSecurityContext:
	    allowPrivilegeEscalation: true
	    capabilities:
	      add:
	      - SETGID
	      - SETUID 

I do think this restriction could be removed, however. If a user is confident in configuring their own SCC as well as the pod & container security contexts, we should assume that they are aware that they might risk breaking workspaces that rely on the container build SCC.

While working on allowing users to configure their workspace pod and container security contexts, I actually vaguely remember trying to do a strategic merge in the case the admin modifies the devEnvironments.security.containerSecurityContext Che Cluster CR field while container builds capabilities are enabled. The idea was to ensure allowPrivilegeEscalation is always set to true and the SETGID, SETUID capabilities are added and never dropped. Unfortunately, this idea was dropped at some point while working on the PR, and the changes were lost.