Security best practices for Eclipse Che

Get an overview of key best security practices for Eclipse Che that can help you foster a more resilient development environment.

Eclipse Che runs on top of OpenShift, which provides the platform, and the foundation for the products functioning on top of it. OpenShift documentation is the entry point for security hardening.

Project isolation in OpenShift

In OpenShift, project isolation is similar to namespace isolation in Kubernetes but is achieved through the concept of projects. A project in OpenShift is a top-level organizational unit that provides isolation and collaboration between different applications, teams, or workloads within a cluster.

By default, Che provisions a unique <username>-devspaces project for each user. Alternatively, the cluster administrator can disable project self-provisioning on the OpenShift level, and turn off automatic namespace provisioning in the CheCluster custom resource:

devEnvironments:
  defaultNamespace:
    autoProvision: false

With this setup, you achieve a curated access to Che, where cluster administrators control provisioning for each user and can explicitly configure various settings including resource limits and quotas. Learn more about project provisioning in the product documentation.

Role-based access control (RBAC)

By default, the Che operator creates the following ClusterRoles:

<namespace>-cheworkspaces-clusterrole
<namespace>-cheworkspaces-devworkspace-clusterrole

The <namespace> prefix corresponds to the project name where the Eclipse Che CheCluster CR is located.

The first time a user accesses Eclipse Che, the corresponding RoleBinding is created in the <username>-devspaces project.

All resources and actions you can grant users permission to use in their namespace is listed below.

Table 1. Overview of resources and actions available in a user’s namespace.
Resources	Actions
pods	"get", "list", "watch", "create", "delete", "update", "patch"
pods/exec	"get", "create"
pods/log	"get", "list", "watch"
pods/portforward	"get", "list", "create"
configmaps	“get", "list", "create", "update", "patch", "delete"
events	“watch”
secrets	"get", "list", "create", "update", "patch", "delete"
services	"get", "list", "create", "delete", "update", "patch"
routes	”get", "list", "create", "delete"
persistentvolumeclaims	“get", "list", "watch", "create", "delete", "update", "patch"
apps/deployments	"get", "list", "watch", "create", "patch", "delete"
apps/replicasets	"get", "list", "patch", "delete"
namespaces	"get", "list"
projects	“get”
devworkspace	"get", "create", "delete", "list", "update", "patch", "watch"
devworkspacetemplates	"get", "create", "delete", "list", "update", "patch", "watch"

Each user is granted permissions only to their namespace, and can not access other user’s resources. Cluster administrators can add extra permissions to users. They should not remove permissions granted by default.

Refer to the product documentation for configuring cluster roles for Eclipse Che users.

More details about the role-based access control are available in the OpenShift documentation.

Dev environment isolation

Isolation of the development environments is implemented using OpenShift projects. Every developer has a project in which the following objects are created and managed:

Cloud Development Environment (CDE) Pods, including the IDE server.
Secrets containing developer credentials, such as a Git token, SSH keys, and a Kubernetes token.
ConfigMaps with developer-specific configuration, such as the Git name and email.
Volumes that persist data such as the source code, even when the CDE Pod is stopped.

Access to the resources in a namespace must be limited to the developer owning it. Granting read access to another developer is equivalent to sharing the developer credentials and should be avoided.

Enhanced authorization

The current trend is to split an infrastructure into several "fit for purpose" clusters instead of having a gigantic monolith OpenShift cluster. However, administrators might still want to provide granular access, and restrict the availability of certain functionalities to particular users.

A "fit for purpose" OpenShift cluster refers to a cluster that is specifically designed and configured to meet the requirements and goals of a particular use case or workload. It is tailored to optimize performance, resource utilization, and other factors based on the characteristics of the workloads it will be managing. For Eclipse Che, it is recommended to have this type of cluster provisioned.

For this purpose, optional properties that you can use to set up granular access for different groups and users are available in the CheCluster Custom Resource:

allowUsers
allowGroups
denyUsers
denyGroups

Below is an example of access configuration:

 networking:
    auth:
      advancedAuthorization:
        allowUsers:
          - user-a
          - user-b
        denyUsers:
          - user-c
        allowGroups:
          - openshift-group-a
          - openshift-group-b
        denyGroups:
          - openshift-group-c

Users in the denyUsers and denyGroup categories will not be able to use Eclipse Che and will see a warning when trying to access the User Dashboard.

Authentication

Only authenticated OpenShift users can access Eclipse Che. The Gateway Pod uses a role-based access control (RBAC) subsystem to determine whether a developer is authorized to access a Cloud Development Environment (CDE) or not.

The CDE Gateway container checks the developer’s Kubernetes roles. If their roles allow access to the CDE Pod, the connection to the development environment is allowed. By default, only the owner of the namespace has access to the CDE Pod.

Access to the resources in a namespace must be limited to the developer owning it. Granting read access to another developer is equivalent to sharing the developer credentials and should be avoided.

Security context and security context constraint

Eclipse Che adds SETGID and SETUID capabilities to the specification of the CDE Pod container security context:

"spec": {
  "containers": [
    "securityContext": {
            "allowPrivilegeEscalation": true,
            "capabilities": {
               "add": ["SETGID", "SETUID"],
               "drop": ["ALL","KILL","MKNOD"]
            },
            "readOnlyRootFilesystem": false,
            "runAsNonRoot": true,
            "runAsUser": 1001110000
   }
  ]
 }

This provides the ability for users to build container images from within a CDE.

By default, Eclipse Che assigns a specific SecurityContextConstraint (SCC) to the users that allows them to start a Pod with such capabilities. This SCC grants more capabilities to the users compared to the default restricted SCC but less capability compared to the anyuid SCC. This default SCC is pre-created in the Che namespace and named container-build.

Setting the following property in the CheCluster Custom Resource prevents assigning extra capabilities and SCC to users:

spec:
  devEnvironments:
    disableContainerBuildCapabilities: true

Resource Quotas and Limit Ranges

Resource Quotas and Limit Ranges are Kubernetes features you can use to help prevent bad actors or resource abuse within a cluster. They help in controlling and managing resource consumption by pods and containers. By combining Resource Quotas and Limit Ranges, you can enforce project-specific policies to prevent bad actors from consuming excessive resources.

These mechanisms contribute to better resource management, stability, and fairness within an OpenShift cluster. More details about Resource Quotas and Limit Ranges are available in the OpenShift documentation.

Disconnected environment

An air-gapped OpenShift disconnected cluster refers to an OpenShift cluster isolated from the internet or any external network. This isolation is often done for security reasons, to protect sensitive or critical systems from potential cyber threats. In an air-gapped environment, the cluster cannot access external repositories or registries to download container images, updates, or dependencies.

Eclipse Che is supported and can be installed in a restricted environment. Installation instructions are available in the official documentation.

Managing extensions

By default, Eclipse Che includes the embedded Open VSX registry which contains a limited set of extensions used by Microsoft Visual Studio Code - Open Source editor. Alternatively, cluster administrators can specify a different plugin registry in the Custom Resource, e.g. https://open-vsx.org that contains thousands of extensions. They can also build a custom Open VSX registry. More details about managing IDE extensions are available in the official documentation.

Installing extra extensions increases potential risks. To minimize these risks, make sure to only install extensions from reliable sources and regularly update them.

Secrets

Keep sensitive data stored as Kubernetes secrets in the users’ namespaces confidential (e.g. Personal Access Tokens (PAT), and SSH keys).

Git repositories

It is crucial to operate within Git repositories that you are familiar with and that you trust. Before incorporating new dependencies into the repository, verify that they are well-maintained and regularly release updates to address any identified security vulnerabilities in their code.