feat(security): Add securityContext and volumeMounts to the container configuration, add volumes to the deployment configuration

[karatkep]

What does this PR do?

• CheCluster API (Deployment / Container)
  Extends component deployment overrides with volumes on the pod, plus per-container securityContext and volumeMounts, wired through the existing override path.

• Deployment overrides (pkg/deploy)

  • Merges securityContext field-by-field into each container (including readOnlyRootFilesystem and related fields).
  • Merges volumeMounts by mount name.
  • Merges pod volumes by volume name.

• pkg/common/utils
  Adds IndexVolume and IndexVolumeMount to support volume / mount merging.

Screenshot/screencast of this PR

What issues does this PR fix or reference?

• Support running Che components (dashboard, server, gateway) with readOnlyRootFilesystem: true che#23791

How to test this PR?

• You can use karatkep/che-operator:7.116.0 for testing
• Don't forget to update CRD
• Enable readOnlyRootFilesystem: true for che-dashboard and che-gateway via CheCluster API:

apiVersion: org.eclipse.che/v2
kind: CheCluster
metadata:
  name: eclipse-che
  namespace: eclipse-che
spec:
  components:
    dashboard:
      deployment:
        containers:
          - securityContext:
              readOnlyRootFilesystem: true
  networking:
    auth:
      gateway:
        deployment:
          containers:
            - name: gateway
              securityContext:
                readOnlyRootFilesystem: true
            - name: configbump
              securityContext:
                readOnlyRootFilesystem: true
              volumeMounts:
                - name: tempdir
                  mountPath: /tmp
            - name: kube-rbac-proxy
              securityContext:
                readOnlyRootFilesystem: true
            - name: oauth-proxy
              securityContext:
                readOnlyRootFilesystem: true
          volumes:
            - name: tempdir
              emptyDir: {}

1. Deploy the operator:

OpenShift

./build/scripts/olm/test-catalog-from-sources.sh

or

build/scripts/docker-run.sh /bin/bash -c "
  oc login \
    --token=<...> \
    --server=<...> \
    --insecure-skip-tls-verify=true && \
  build/scripts/olm/test-catalog-from-sources.sh
"

on Minikube

./build/scripts/minikube-tests/test-operator-from-sources.sh

Common Test Scenarios

• Deploy Eclipse Che
• Start an empty workspace
• Open terminal and build/run an image
• Stop a workspace
• Check operator logs for reconciliation errors or infinite reconciliation loops

PR Checklist

As the author of this Pull Request I made sure that:

• The Eclipse Contributor Agreement is valid
• Code produced is complete
• Code builds without errors
• Tests are covering the bugfix
• The repository devfile is up to date and works
• Relevant user documentation updated
• Relevant contributing documentation updated
• CI/CD changes implemented, documented and communicated

Reviewers

Reviewers, please comment how you tested the PR when approving it.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: karatkep

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

Details

Needs approval from an approver in each of these files:

• OWNERS

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

[openshift-ci]

Hi @karatkep. Thanks for your PR.

I'm waiting for a eclipse-che member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Tip

We noticed you've done this a few times! Consider joining the org to skip this step and gain /lgtm and other bot rights. We recommend asking approvers on your previous PRs to sponsor you.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[karatkep]

Hello @tolusha,
Could I ask someone from your team to help me with update-dev-resources? It seems I am using different versions of the tooling, so the updated resources include not only my additions but also a lot of formatting changes to the existing code.
Thank you in advance!

[tolusha]

Hello, @karatkep
Thank you for contribution.
We can simply force to set readOnlyRootFilesystem=true here [1], I don't think we need this configurable.
Having that, configbump fails to start

{"level":"error","ts":1775208352.9685433,"logger":"config-bump","caller":"zapr@v0.1.0/zapr.go:128","msg":"Could not initialize the config map sync controller","error":"open /tmp/operator-sdk-ready: read-only file system","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-logr/zapr@v0.1.0/zapr.go:128\nmain.main\n\t/app/cmd/configbump/main.go:65\nruntime.main\n\t/usr/lib/golang/src/runtime/proc.go:272"}

This can be fixed by updating dependencies in [2]
Probably, we won't need volumes configuration is this case.

[1]

che-operator/pkg/deploy/deployment.go

Line 271 in 5748764

}

[2] che-incubator/configbump#201

[karatkep]

@tolusha, that was my initial idea - a simple and fast solution. However, I encountered some issues:

• che-server requires two writable folders: /tmp and /home/user
• configbump requires a writable folder: /tmp

Note: I haven’t tested this approach with dev-registry and plugin-registry yet.

Given these challenges, I decided to propose a more complex but configurable solution, which would give users greater flexibility to tailor their environment to their needs.

Personally, I’m fine with making a few code changes to set readOnlyRootFilesystem=true. However, I definitely need advice from the maintainers to avoid any potential pitfalls or unintended consequences.

If you have any recommendations or best practices, I’d really appreciate your input!