Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 4. Configure server components

Mount OpenShift Secrets and ConfigMaps into OpenShift Dev Spaces containers to provide configuration files, credentials, and environment variables without modifying container images.

You can mount Secrets and ConfigMaps as files, as subpath volumes, or as environment variables. Each method requires specific annotations and labels on the OpenShift resource.

4.1. Mount a Secret or a ConfigMap as a file
Copy link

Mount an OpenShift Secret or a ConfigMap as a file into an OpenShift Dev Spaces container to provide configuration files, certificates, or credentials without embedding them in the container image.

Prerequisites

  • You have a running instance of Red Hat OpenShift Dev Spaces.

Procedure

  1. Create a new OpenShift Secret or a ConfigMap in the OpenShift project where OpenShift Dev Spaces is deployed with the required labels: 

    apiVersion: v1
kind: Secret
metadata:
  name: custom-settings
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: <DEPLOYMENT_NAME>-<OBJECT_KIND>
...

    where:

    kind
    Secret for a Secret or ConfigMap for a ConfigMap.
    <DEPLOYMENT_NAME>
    Target deployment: devspaces, devspaces-dashboard, devfile-registry, or plugin-registry.
    <OBJECT_KIND>
    secret for a Secret or configmap for a ConfigMap.

  2. Configure the annotation values. Annotations must indicate that the given object is mounted as a file:

    • che.eclipse.org/mount-as: file - Mounts an object as a file.

    • che.eclipse.org/mount-path: <TARGET_PATH> - To provide a required mount path.

      For a Secret: 

      apiVersion: v1
kind: Secret
metadata:
  name: custom-data
  annotations:
    che.eclipse.org/mount-as: file
    che.eclipse.org/mount-path: /data
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-secret
...

      For a ConfigMap: 

      apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-data
  annotations:
    che.eclipse.org/mount-as: file
    che.eclipse.org/mount-path: /data
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
...

  3. Add data items to the object. Each item name must match the desired file name mounted into the container.

    For a Secret: 

    apiVersion: v1
kind: Secret
metadata:
  name: custom-data
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-secret
  annotations:
    che.eclipse.org/mount-as: file
    che.eclipse.org/mount-path: /data
data:
  ca.crt: <base64 encoded data content here>

    For a ConfigMap: 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-data
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
  annotations:
    che.eclipse.org/mount-as: file
    che.eclipse.org/mount-path: /data
data:
  ca.crt: <data content here>

Verification

  • Verify that the file is mounted in the target container: 

    oc exec -n openshift-devspaces deploy/<DEPLOYMENT_NAME> -- ls <TARGET_PATH>/<FILE_NAME>

    Each data item name in the object corresponds to a file name at the mount path. For example, a data item named ca.crt with a mount path of /data results in a file at /data/ca.crt.

    Important

    If you update the Secret or ConfigMap data, re-create the object entirely to make the changes visible in the OpenShift Dev Spaces container.

4.2. Mount a Secret or a ConfigMap as a subPath
Copy link

Mount an OpenShift Secret or a ConfigMap as a subPath to add individual files to a target directory without replacing existing contents. Use a subPath mount when the target directory already contains files that must be preserved.

Prerequisites

  • You have a running instance of Red Hat OpenShift Dev Spaces.

Procedure

  1. Create a new OpenShift Secret or a ConfigMap in the OpenShift project where OpenShift Dev Spaces is deployed with the required labels: 

    apiVersion: v1
kind: Secret
metadata:
  name: custom-settings
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: <DEPLOYMENT_NAME>-<OBJECT_KIND>
...

    where:

    kind
    Secret for a Secret or ConfigMap for a ConfigMap.
    <DEPLOYMENT_NAME>
    Target deployment: devspaces, devspaces-dashboard, devfile-registry, or plugin-registry.
    <OBJECT_KIND>
    secret for a Secret or configmap for a ConfigMap.

  2. Configure the annotation values. Annotations must indicate that the given object is mounted as a subPath:

    • che.eclipse.org/mount-as: subpath - Mounts an object as a subPath.

    • che.eclipse.org/mount-path: <TARGET_PATH> - To provide a required mount path.

      For a Secret: 

      apiVersion: v1
kind: Secret
metadata:
  name: custom-data
  annotations:
    che.eclipse.org/mount-as: subpath
    che.eclipse.org/mount-path: /data
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-secret
...

      For a ConfigMap: 

      apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-data
  annotations:
    che.eclipse.org/mount-as: subpath
    che.eclipse.org/mount-path: /data
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
...

  3. Add data items to the object. Each item name must match the file name mounted into the container.

    For a Secret: 

    apiVersion: v1
kind: Secret
metadata:
  name: custom-data
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-secret
  annotations:
    che.eclipse.org/mount-as: subpath
    che.eclipse.org/mount-path: /data
data:
  ca.crt: <base64 encoded data content here>

    For a ConfigMap: 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-data
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
  annotations:
    che.eclipse.org/mount-as: subpath
    che.eclipse.org/mount-path: /data
data:
  ca.crt: <data content here>

Verification

  • Verify that the file is mounted in the target container: 

    oc exec -n openshift-devspaces deploy/<DEPLOYMENT_NAME> -- ls <TARGET_PATH>/<FILE_NAME>

    Each data item name in the object corresponds to a file name at the mount path. For example, a data item named ca.crt with a mount path of /data results in a file at /data/ca.crt.

    Important

    If you update the Secret or ConfigMap data, re-create the object entirely to make the changes visible in the OpenShift Dev Spaces container.

Mount an OpenShift Secret or a ConfigMap as an environment variable in an OpenShift Dev Spaces container. This injects configuration values such as credentials, API keys, or feature flags without modifying the container image.

Prerequisites

  • You have a running instance of Red Hat OpenShift Dev Spaces.

Procedure

  1. Create a new OpenShift Secret or a ConfigMap in the OpenShift project where OpenShift Dev Spaces is deployed with the required labels: 

    apiVersion: v1
kind: Secret
metadata:
  name: custom-settings
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: <DEPLOYMENT_NAME>-<OBJECT_KIND>
...

    where:

    kind
    Secret for a Secret or ConfigMap for a ConfigMap.
    <DEPLOYMENT_NAME>
    Target deployment: devspaces, devspaces-dashboard, devfile-registry, or plugin-registry.
    <OBJECT_KIND>
    secret for a Secret or configmap for a ConfigMap.

  2. Configure the annotation values. Annotations must indicate that the given object is mounted as an environment variable:

    • che.eclipse.org/mount-as: env - Mounts an object as an environment variable.

    • che.eclipse.org/env-name: <FOO_ENV> - Provides the environment variable name, which is required to mount an object key value.

      For a Secret: 

      apiVersion: v1
kind: Secret
metadata:
  name: custom-settings
  annotations:
    che.eclipse.org/env-name: FOO_ENV
    che.eclipse.org/mount-as: env
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-secret
stringData:
  mykey: myvalue

      For a ConfigMap: 

      apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-settings
  annotations:
    che.eclipse.org/env-name: FOO_ENV
    che.eclipse.org/mount-as: env
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
data:
  mykey: myvalue

  3. If the object provides more than one data item, provide the environment variable name for each data key by using the che.eclipse.org/<key>_env-name annotation format.

    For a Secret: 

    apiVersion: v1
kind: Secret
metadata:
  name: custom-settings
  annotations:
    che.eclipse.org/mount-as: env
    che.eclipse.org/mykey_env-name: FOO_ENV
    che.eclipse.org/otherkey_env-name: OTHER_ENV
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-secret
stringData:
  mykey: <data_content_here>
  otherkey: <data_content_here>

    For a ConfigMap: 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-settings
  annotations:
    che.eclipse.org/mount-as: env
    che.eclipse.org/mykey_env-name: FOO_ENV
    che.eclipse.org/otherkey_env-name: OTHER_ENV
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
data:
  mykey: <data content here>
  otherkey: <data content here>

    The maximum length of annotation names in an OpenShift object is 63 characters, where 9 characters are reserved for a prefix that ends with /. This restricts the maximum length of the key that can be used for the object.

Verification

  • Verify that the environment variable is set in the target container: 

    oc exec -n openshift-devspaces deploy/<DEPLOYMENT_NAME> -- env | grep <ENV_NAME>

    For a single-key object, both the env-name value and the data key name become environment variables. For a multi-key object, only the per-key env-name values are provisioned.

    Important

    If you update the Secret or ConfigMap data, re-create the object entirely to make the changes visible in the OpenShift Dev Spaces container.

Advanced configuration of the OpenShift Dev Spaces server allows you to set environment variables or override properties that are not exposed through the standard CheCluster Custom Resource fields.

Advanced configuration is necessary to:

  • Add environment variables not automatically generated by the Operator from the standard CheCluster Custom Resource fields.
  • Override the properties automatically generated by the Operator from the standard CheCluster Custom Resource fields.

The customCheProperties field, part of the CheCluster Custom Resource server settings, contains a map of additional environment variables to apply to the OpenShift Dev Spaces server component.

  • Configure the CheCluster Custom Resource. 

    apiVersion: org.eclipse.che/v2
kind: CheCluster
spec:
  components:
    cheServer:
      extraProperties:
        CHE_LOGS_APPENDERS_IMPL: json
Note

Previous versions of the OpenShift Dev Spaces Operator had a ConfigMap named custom to fulfill this role. If the OpenShift Dev Spaces Operator finds a configMap with the name custom, it adds the data into the customCheProperties field. The Operator then redeploys OpenShift Dev Spaces and deletes the custom configMap.

Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Legal Notice

Theme

© 2026 Red HatBack to top