OpenShift Dev Spaces applies these protections automatically when you install it. No configuration is required:

These security tasks require administrator action:

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

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

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, OpenShift Dev Spaces 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 OpenShift Dev Spaces. 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.

By default, the OpenShift Dev Spaces operator creates the following ClusterRoles:

The <namespace> prefix corresponds to the project name where the Red Hat OpenShift Dev Spaces CheCluster CR is located. The first time a user accesses Red Hat OpenShift Dev Spaces, 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.

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

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

Users on a deny list cannot use OpenShift Dev Spaces 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.

Only authenticated OpenShift users can access Red Hat OpenShift Dev Spaces. 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.

Red Hat OpenShift Dev Spaces 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, Red Hat OpenShift Dev Spaces 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 OpenShift Dev Spaces 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 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 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:

When configuring network policies for Red Hat OpenShift Dev Spaces, ensure that pods in the OpenShift Dev Spaces 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.

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.

OpenShift Dev Spaces 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.

By default, Red Hat OpenShift Dev Spaces 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.

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

Developer credentials such as personal access tokens (PATs), SSH keys, and Kubernetes tokens are stored as Secrets in each user’s project. 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.

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.

Grant your developers additional OpenShift permissions by adding cluster roles so they can access resources beyond the default workspace operations.

Restrict OpenShift Dev Spaces access to specific users and groups so that you can control which users are allowed or denied access to the platform.

Remove a user’s data from OpenShift Container Platform when a developer leaves your organization, to comply with the Content from gdpr.eu is not included.General Data Protection Regulation (GDPR). The process for other Kubernetes infrastructures might vary.

Revised on 2026-07-27 19:48:02 UTC