Configure Red Hat OpenShift Dev Spaces for enterprise security

As platform engineering teams standardize cloud-native developer environments, balancing developer experience with strict enterprise security becomes paramount. Red Hat OpenShift Dev Spaces provides the foundation for security-focused, scalable development. Building on the groundwork established in Build a multi-tenant platform with OpenShift Dev Spaces, this follow-up guide explores how to configure SCM integration, deploy an internal private extension registry, and enable flexible JetBrains IDE workflows in enterprise networks.

SCM integration and certificate trust to automate secure Git access 

Red Hat OpenShift Dev Spaces automatically synchronizes with your source code management (SCM) provider to simplify authentication. Configuring this integration globally means developers never have to manually manage SSH keys or handle static personal access tokens (PATs) on their local machines.

Create the SCM OAuth application

To establish instance-wide authentication, configure a dedicated OAuth application within your SCM provider. This application acts as the centralized identity bridge between OpenShift Dev Spaces and your Git host. Baseline parameters:

• Application name: Red Hat OpenShift Dev Spaces
• Redirect URI: https://<devspaces-dashboard-url>/api/oauth/callback
• Scopes: api, write_repository, openid

Once saved, the provider generates an application ID (client ID) and a client secret. Both need to be saved as a Kubernetes Secret in the cluster.

Deploy the SCM OAuth secret

The OAuth secret must be deployed into the global operator namespace (openshift-devspaces), not the CheCluster namespace—the DevWorkspace controller watches this namespace to map tokens dynamically into developer pods during workspace initialization.

apiVersion: v1
kind: Secret
metadata:
  name: scm-oauth-config
  namespace: openshift-devspaces  # Must reside in the operator namespace
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: oauth-scm-configuration  # Mandatory component identifier
  annotations:
    che.eclipse.org/oauth-scm-server: "gitlab"             # Identifies the target SCM type
    che.eclipse.org/scm-server-endpoint: "https://git.enterprise.com"  # Target provider URL
type: Opaque
stringData:
  id: "EXPLICIT_SCM_APPLICATION_ID"      # Generated Client ID
  secret: "EXPLICIT_SCM_CLIENT_SECRET"   # Generated Client Secret

Reduce etcd overhead and resolve internal PKI trust

By default, the Dev Spaces operator generates a large ca-certs-merged ConfigMap containing the full CA bundle, and mounts a copy of it into every user namespace. At enterprise scale, with hundreds of namespaces each holding a full copy of that bundle, this becomes a real contributor to the etcd pressure covered in part 1.

Setting disableWorkspaceCaBundleMount: true in the CheCluster custom resource (CR) stops this default mount entirely.

The trade-off: Once disabled, nothing is mounted under the trust path unless you explicitly supply it—only custom certificates you provide get mounted under /public-certs. This is what makes the follow-up ConfigMap mandatory: On-premise SCM instances signed by an internal corporate PKI will otherwise fail workspace Git operations with TLS handshake rejections because there is no longer a default CA bundle.

spec:
  devEnvironments:
    trustedCerts:
      disableWorkspaceCaBundleMount: true               # Stops the default per-namespace CA bundle mount
      gitTrustedCertsConfigMapName: che-git-custom-cert    # Supplies your corporate PKI explicitly

The referenced ConfigMap must be created in the devspaces-checluster namespace, with 2 required keys:

• ca.crt: The corporate CA certificate bundle content
• githost: Your Git provider's base URL (for example, https://git.enterprise.com)

Keep certificate rotation in mind: Setting disableWorkspaceCaBundleMount: true makes workspaces entirely dependent on the static contents of this ConfigMap. When your enterprise PKI root certificates rotate, the platform does not automatically refresh running workspaces. Cluster administrators must delete and recreate the che-git-custom-cert ConfigMap, and developers must restart their workspaces to pick up the updated trust chain.

Air-gapped architecture and governance for a private extension registry

Red Hat OpenShift Dev Spaces uses the Open VSX Registry as its default source for Visual Studio Code extensions. Restricted network environments keep unvetted code off your network, but blocking external access can stall development. Hosting an internal extension registry gives platform teams total oversight while giving developers instant access to pre-approved tools.

To achieve complete network isolation, deploy an on-premise OpenVSX server inside the cluster's Secure Asset Zone (devspaces-openvsx) and configure Dev Spaces to pull extensions exclusively from that curated instance.

Simplified PostgreSQL-only architecture

The standard upstream OpenVSX deployment includes an Elasticsearch component to support full-text search across thousands of extensions. For an internal corporate registry hosting a curated catalog—typically dozens or a few hundred approved extensions—Elasticsearch adds unnecessary memory footprint, storage demands, and deployment complexity.

Dropping Elasticsearch in favor of a PostgreSQL-only architecture significantly reduces the resource footprint while still supporting fast, reliable extension discovery at this scale. Refer to Red Hat OpenShift Dev Spaces documentation for installing a private Open VSX registry on OpenShift.

Automated publishing governance

Rather than allowing unrestricted downloads, the automation evaluates every extension added to the internal Open VSX catalog against strict versioning filters before publishing it to the registry.

Publishing is also version-aware and idempotent. The automation publishes only when the local package is newer than what's already in the registry, and it updates a tracking manifest afterward so subsequent pipeline runs skip anything already published and validated.

Point OpenShift Dev Spaces to the private registry

Once the internal OpenVSX server is running in devspaces-openvsx, route all workspace extension queries to it by updating the pluginRegistry block in the CheCluster CR:

spec:
  components:
    pluginRegistry:
      openVSXURL: "http://openvsx-server.openvsx.svc:8080" # Internal openvsx service url

Developer extension lifecycle

This establishes a clean, governed workflow for development teams:

1. Submit: Developers request missing tooling via a service catalog or Git request.
2. Review: The platform team reviews the request; automated scanning (see Automated publishing governance) will supplement this step once implemented.
3. Promote: Approved extensions are synced into the internal OpenVSX registry and become available across all workspace instances.

Enable IntelliJ IDEA and remote gateway support

Forcing every engineer into a single browser-based editor rarely works. Java and polyglot developers depend on IntelliJ IDEA for deep code navigation and refactoring—and preserving that familiar workflow keeps them in flow.

OpenShift Dev Spaces addresses this by decoupling the developer's client interface from the remote workspace pod. Through JetBrains Gateway integration, developers run the JetBrains Client UI on their local workstation while all compilation, indexing, and runtime execution happen inside the OpenShift workspace pod.

Red Hat support caution

JetBrains Gateway support for OpenShift Dev Spaces has historically been introduced and expanded as a technology preview feature, with additional JetBrains IDEs (PhpStorm, GoLand) added in later releases. Confirm the current support status against Red Hat's documentation for your specific OpenShift Dev Spaces version before committing to it for production developer workflows.

Hosting IDE binaries in restricted networks

In air-gapped or network-restricted environments, workspace pods cannot reach public JetBrains distribution servers (download.jetbrains.com) to pull the required IDE tarballs during workspace initialization.

To support JetBrains IDEs in an air-gapped cluster, mirror the IDE archive to an internal artifact repository such as JFrog Artifactory or Sonatype Nexus and configure OpenShift Dev Spaces to source the binary locally.

1. Mirror the IDE binary. Download the target archive from the vendor distribution point and upload it to your internal artifact manager:
   • Source: https://download.jetbrains.com/idea/ideaIU-2025.2.tar.gz
   • Internal target example: https://nexus.enterprise.com/rh-devspaces-artifacts/intellij/ideaIU-2025.2.tar.gz

2. Configure editorsDownloadUrls in the CheCluster CR. Redirect requests for the IntelliJ editor image to your internal endpoint:

   spec:
     devEnvironments:
       editorsDownloadUrls:
         - editor: "che-incubator/che-idea-server/latest"
           url: "https://nexus.enterprise.com/rh-devspaces-artifacts/intellij/ideaIU-2025.2.tar.gz"

When a developer creates a workspace and selects IntelliJ IDEA, the editor injection container pulls the binary from your internal Nexus or Artifactory instance, ensuring reliable startup without external network dependencies.

Connect via JetBrains Gateway

Platform administrators can guide development teams on connecting local IntelliJ IDE instances to running OpenShift Dev Spaces workspaces using 2 primary workflows:

1. Dashboard-initiated (the default, simplest path). Developers start a workspace from the OpenShift Dev Spaces dashboard and select the IntelliJ IDEA Ultimate editor. When the workspace is ready, a prompt appears to open JetBrains Gateway—clicking it launches the local JetBrains client, already connected to that workspace.
2. Gateway-initiated (direct, no dashboard needed). Developers launch JetBrains Gateway locally and select the OpenShift Dev Spaces provider plug-in without visiting the dashboard first. Gateway then lists your active DevWorkspacesinstances directly, and selecting one establishes the connection.

Both paths rely on the same prerequisite: An authenticated local session with oc login against your OpenShift cluster. The Gateway provider plug-in reads that session's connection details from your local OpenShift client configuration—there's no separate token entry step.

Enterprise licensing and community alternatives

When planning JetBrains enablement for enterprise teams, account for vendor licensing:

• IntelliJ IDEA Ultimate requires an active, paid JetBrains subscription. Confirm with JetBrains whether your organization's licensing terms cover this remote/server-based usage pattern specifically, since license terms for desktop versus remote development can differ.
• IntelliJ IDEA Community Edition is also available as a no-cost alternative that requires no commercial license, for teams that don't need Ultimate's enterprise-framework tooling. The exact editor identifier and packaging for Community Edition have changed across OpenShift Dev Spaces releases—confirm the current value against Red Hat's documentation for your target version rather than hardcoding one here.

Next steps for your platform team

By centralizing SCM authentication, curating an internal extension registry, and enabling preferred IDEs, platform teams can offer a smooth, cloud-native workspace experience.

In part 3 of this series, we'll explore production caveats, CI/CD pipeline automation, observability, and air-gapped considerations to help you prepare for a full-scale enterprise rollout.

Ready to see how a standardized, security-focused cloud development environment can elevate your developer experience? Try Red Hat OpenShift Dev Spaces in our no-cost Developer Sandbox.