Protect your deployment

Protect your Eclipse Che deployment by applying these security practices to safeguard developer credentials, isolate workspaces, and reduce the cluster attack surface.

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.

What is secure by default

Che applies these protections automatically when you install it. No configuration is required:

Project isolation. Each developer gets a dedicated <username>-devspaces namespace. Users cannot access other users' resources.
Role-based access control (RBAC). The Operator creates ClusterRoles that grant developers permissions only within their own namespace.
Authentication. Only authenticated OpenShift users can access Che. The gateway enforces RBAC on every request.
Container security context. Workspace pods run as non-root with dropped capabilities. The container-build SecurityContextConstraint adds only SETGID and SETUID for container builds.

What you must configure

These security tasks require administrator action:

OAuth for Git providers. Without OAuth, developers must manually create personal access token secrets. Set up OAuth for your Git providers to give developers credential-free repository access.
Access restrictions. By default, all authenticated OpenShift users can access Che. Use the advancedAuthorization CheCluster property to restrict access to specific users and groups.

What you can optionally harden

These additional measures strengthen your security posture but are not required:

Network policies. Control ingress and egress traffic between workspace pods to limit the attack surface.
Resource quotas and limit ranges. Prevent resource abuse by setting per-project consumption constraints.
Extension management. Restrict IDE extensions to trusted sources, especially in air-gapped environments.
Self-signed certificates. Import custom TLS certificates if your Git server or artifact repositories use internal certificate authorities.

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 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 Provisioning namespaces in advance.

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.

The following table lists the resources and actions that you can grant users permission to use in their namespace.

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	"list", "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 cannot access other users' resources. Cluster administrators can add extra permissions to users. They should not remove permissions granted by default.

For more details about configuring cluster roles for Eclipse Che users and role-based access control, see the Additional resources section.

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 Integrated Development Environment (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. A "fit for purpose" cluster is specifically designed and configured to meet the requirements of a particular use case or workload. It is tailored to optimize performance and resource utilization based on the characteristics of the workloads it manages.

For Eclipse Che, this type of cluster is recommended. However, administrators might still want to provide granular access and restrict the availability of certain functionalities to particular users.

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

allowUsers
allowGroups
denyUsers
denyGroups

The following example shows an 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 cannot use Eclipse Che and see a warning when trying to access the User Dashboard.

Authentication and access verification

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.

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 users a specific SecurityContextConstraint (SCC) 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 and resource abuse within a cluster. Specifically, they allow you to set resource consumption constraints for 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.

Network policies

Network policies provide an additional layer of security by controlling network traffic between pods in a Kubernetes cluster. By default, every pod can communicate with every other pod and service on the cluster.

Implementing network policies allows you to:

Control ingress and egress traffic to and from workspace pods
Limit the attack surface by denying unauthorized network access

When configuring network policies for Eclipse Che, ensure that pods in the Che namespace can still communicate with pods in user namespaces. This communication is required for proper functionality.

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.

Extension security

By default, Eclipse Che includes the embedded Open VSX registry which contains a limited set of extensions for the Microsoft Visual Studio Code - Open Source editor. Alternatively, cluster administrators can specify a different plugin registry in the Custom Resource, for example the open-vsx.org registry that contains thousands of extensions. They can also build a custom Open VSX registry.

Installing extra extensions increases potential risks. To minimize these risks, ensure that you only install extensions from reliable sources and regularly update them.

Credential and secret protection

Keep sensitive data stored as Kubernetes secrets in the users' namespaces confidential (for example 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.

Additional resources