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.

For Git OAuth setup and for restricting platform access, see Additional resources.

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 for developer workspaces

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. Cluster administrators control provisioning for each user and can explicitly configure various settings including resource limits and quotas. For more information about provisioning projects in advance, see Additional resources.

Default RBAC permissions for workspace users

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.

What runs in each developer namespace

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.

Restrict platform access with allow and deny lists

By default, every authenticated OpenShift user can access Che. To limit the platform to specific users and groups, configure the advancedAuthorization properties in the CheCluster Custom Resource:

allowUsers
allowGroups
denyUsers
denyGroups

Users on a deny list cannot use Che and see a warning when they try to open the User Dashboard. If a user appears on both allow and deny lists, access is denied. For the procedure to configure allow and deny lists, see Additional resources.

How gateway authentication controls access

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 for container builds

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. For more information about resource quotas and limit ranges, see Additional resources.

Network policies for workspace pods

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. For detailed instructions on configuring network policies, see Additional resources.

Security in disconnected and air-gapped deployments

In a disconnected or air-gapped OpenShift cluster, nodes cannot reach public registries or the internet. That isolation reduces exposure to external threats, but you must supply container images, IDE extensions, and dependencies from internal registries that you control.

Che supports restricted-network installation. For installation steps, see Additional resources. Restrict IDE extensions to trusted internal sources as described in Secure IDE extensions in workspaces.

Secure IDE extensions in workspaces

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.

For more information about managing IDE extensions, see Additional resources.

Protect developer credentials and secrets

Developer credentials such as personal access tokens (PATs), SSH keys, and Kubernetes tokens are stored as Secrets in each user’s namespace. Treat those Secrets as confidential. Granting another user read access to a developer namespace is equivalent to sharing that developer’s credentials.

Prefer organization-wide Git OAuth so developers do not create and store long-lived personal tokens in every Cloud Development Environment. For Git OAuth setup and for mounting secrets into workspaces, see Additional resources.

Trusted Git repositories and dependencies

Operate only on Git repositories that your organization trusts. Before adding new dependencies, confirm that maintainers publish security updates for known vulnerabilities. Untrusted repositories and outdated dependencies increase supply-chain risk for every Cloud Development Environment that clones them.

For credential-free Git access that reduces token sprawl, see Additional resources.

Additional resources