Skip to main content
Version: Next

Red Hat OpenShift

Red Hat OpenShift, a Kubernetes distribution maintained by Red Hat, provides options for both managed and on-premises hosting.

note

Deploying Camunda 8 on Red Hat OpenShift is achievable using Helm, given the appropriate configurations. However, it's important to note that the Security Context Constraints (SCCs) and Routes configurations might require slight deviations from the guidelines provided in the general Helm deployment guide.

Cluster Specification​

When deploying Camunda 8 on an OpenShift cluster, the cluster specification should align with your specific requirements and workload characteristics. Here's a suggested configuration to begin with:

  • Instance type: 4 vCPUs (x86_64, >3.1 GHz), 16 GiB Memory (for example, m5.xlarge on AWS)
  • Number of dedicated nodes: 4
  • Volume type: SSD volumes (with between 1000 and 3000 IOPS per volume, and a throughput of 1,000 MB/s per volume, for instance, gp3 on AWS)

Supported Versions​

We conduct testing and ensure compatibility against the following OpenShift versions:

OpenShift VersionEnd of Support Date
4.16.xDecember 27, 2025
4.15.xAugust 27, 2025
4.14.xMay 1, 2025
4.13.xNovember 17, 2024
caution

Compatibility is not guaranteed for OpenShift versions no longer supported by Red Hat, as per the End of Support Date. For more information, refer to the Red Hat OpenShift Container Platform Life Cycle Policy.

Deploying Camunda 8 in OpenShift​

Depending on your OpenShift cluster's Security Context Constraints (SCCs) configuration, the deployment process may vary.

With restrictive SCCs​

By default, OpenShift employs more restrictive SCCs. The Helm chart must assign null to the user running all components and dependencies. The global.compatibility.openshift.adaptSecurityContext variable in your values.yaml can be used to set the following possible values:

  • force: The runAsUser and fsGroup values will be null in all components.
  • disabled: The runAsUser and fsGroup values will not be modified (default).

To deploy Camunda 8 on OpenShift:

  1. Install Helm and other CLI tools.
  2. Install the Camunda Helm chart repository.
  3. Set global.compatibility.openshift.adaptSecurityContext to force
helm install camunda camunda/camunda-platform --skip-crds \
  --set global.compatibility.openshift.adaptSecurityContext=force

Available Configurations of OpenShift Components​

Security Context Constraints (SCCs)​

Security Context Constraints (SCCs) are a set of conditions that a pod must adhere to in order to be accepted into the system. They define the security conditions under which a pod operates.

Similar to how roles control user permissions, SCCs regulate the permissions of deployed applications, both at the pod and container level. It's generally recommended to deploy applications with the most restrictive SCCs possible. If you're unfamiliar with security context constraints, you can refer to the OpenShift documentation.

Restrictive SCCs​

The following represents the most restrictive SCCs that can be used to deploy Camunda 8. Note that in OpenShift 4.10, these are equivalent to the built-in restricted SCCs (which are the default SCCs).

Allow Privileged: false
Default Add Capabilities: <none>
Required Drop Capabilities: KILL, MKNOD, SYS_CHROOT, SETUID, SETGID
Allowed Capabilities: <none>
Allowed Seccomp Profiles: <none>
Allowed Volume Types: configMap, downwardAPI, emptyDir, persistentVolumeClaim, projected, secret
Allow Host Network: false
Allow Host Ports: false
Allow Host PID: false
Allow Host IPC: false
Read Only Root Filesystem: false
Run As User Strategy: MustRunAsRange
SELinux Context Strategy: MustRunAs
FSGroup Strategy: MustRunAs
Supplemental Groups Strategy: RunAsAny

When using these SCCs, be sure not to specify any runAsUser or fsGroup values in either the pod or container security context. Instead, allow OpenShift to assign arbitrary IDs.

note

If you are providing the ID ranges yourself, you can also configure the runAsUser and fsGroup values accordingly.

The Camunda Helm chart can be deployed to OpenShift with a few modifications, primarily revolving around your desired security context constraints.

Ingress Configuration​

Before exposing services outside the cluster, we need an Ingress component. Here's how you can configure it:

Using Kubernetes Ingress​

Routes serve as OpenShift's default Ingress implementation.

If you find that its features aren't suitable for your needs, or if you prefer to use a Kubernetes-native Ingress controller, such as the ingress-nginx controller, you have that option.

For guidance on installing an Ingress controller, you can refer to the Ingress Setup documentation.

Difference between ingress-nginx and NGINX Ingress

Do not confuse the ingress-nginx controller with the NGINX Ingress Controller that is endorsed by Red Hat for usage with OpenShift. Despite very similar names, they are two different products.

If you should decide to use the Red Hat endorsed NGINX Ingress Controller, you would require additional adjustments done to the Camunda 8 Ingress objects and the NGINX Ingress Controller itself to make gRPC and HTTP/2 connections work. In that case, please refer to the example and the prerequisites.

Pitfalls to avoid​

For general deployment pitfalls, visit the deployment troubleshooting guide.