diff --git a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
index 04c3fdfc58..006d0b596e 100644
--- a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -9,7 +9,9 @@ import TabItem from '@theme/TabItem';
Red Hat OpenShift, a Kubernetes distribution maintained by [Red Hat](https://www.redhat.com/en/technologies/cloud-computing/openshift), provides options for both managed and on-premise 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)](#security-context-constraints-sccs) and [Routes](./redhat-openshift.md?current-ingress=openshift-routes#using-openshift-routes) configurations might require slight deviations from the guidelines provided in the [general Helm deployment guide](/self-managed/setup/install.md).
+:::
## Cluster Specification
@@ -23,57 +25,62 @@ When deploying Camunda 8 on an OpenShift cluster, the cluster specification shou
We conduct testing and ensure compatibility against the following OpenShift versions:
-- Compatibility is not guaranteed for OpenShift versions no longer supported by Red Hat, as indicated in the "End of Support Date" column.
-
| OpenShift Version | [End of Support Date](https://access.redhat.com/support/policy/updates/openshift) |
| ----------------- | --------------------------------------------------------------------------------- |
+| 4.16.x | December 27, 2025 |
| 4.15.x | August 27, 2025 |
| 4.14.x | May 1, 2025 |
| 4.13.x | November 17, 2024 |
-| 4.12.x | July 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](https://access.redhat.com/support/policy/updates/openshift).
+:::
## 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. Due to a [null bug](https://github.com/helm/helm/issues/9136) [in Helm](https://github.com/helm/helm/issues/12490), this operation must be executed using our OpenShift values.yaml
+By default, OpenShift employs more restrictive SCCs.
+
+- The Helm chart must assign `null` to the user running all components and dependencies.
+- Due to a [null bug](https://github.com/helm/helm/issues/9136) [in Helm](https://github.com/helm/helm/issues/12490), this operation must be executed using our `OpenShift values.yaml` file.
-To deploy Camunda 8 on OpenShift, please follow these installation steps:
+To deploy Camunda 8 on OpenShift:
1. Install [Helm and other CLI tools](/self-managed/setup/install.md#prerequisites).
-2. Install the [Camunda Helm chart repository](/self-managed/setup/install.md#helm-repository).
-3. Download the exact version of the chart that you want to install and extract it in a directory ([Camunda 8 Helm Chart Version Matrix](https://helm.camunda.io/camunda-platform/version-matrix/)):
+1. Install the [Camunda Helm chart repository](/self-managed/setup/install.md#helm-repository).
+1. Download the exact version of the chart you want to install and extract it in a directory ([Camunda 8 Helm Chart Version Matrix](https://helm.camunda.io/camunda-platform/version-matrix/)):
-```shell
-# List of available versions: https://helm.camunda.io/camunda-platform/version-matrix/
-export CHART_VERSION=""
+ ```shell
+ # List of available versions: https://helm.camunda.io/camunda-platform/version-matrix/
+ export CHART_VERSION=""
-# Make sure to set CHART_VERSION to match the chart version you want to install.
-helm pull camunda/camunda-platform --version "$CHART_VERSION" --untar --untardir "/tmp/camunda-platform-$CHART_VERSION"
-```
+ # Make sure to set CHART_VERSION to match the chart version you want to install.
+ helm pull camunda/camunda-platform --version "$CHART_VERSION" --untar --untardir "/tmp/camunda-platform-$CHART_VERSION"
+ ```
-5. Install the Camunda chart with the patched SCCs (`/tmp/camunda-platform-CHART_VERSION/camunda-platform/openshift/values.yaml`)
+1. Install the Camunda chart with the patched SCCs (`/tmp/camunda-platform-CHART_VERSION/camunda-platform/openshift/values.yaml`).
-```shell
-helm install camunda camunda/camunda-platform --skip-crds --version "$CHART_VERSION" \
- --values "/tmp/camunda-platform-$CHART_VERSION/camunda-platform/openshift/values.yaml"
-```
+ ```shell
+ helm install camunda camunda/camunda-platform --skip-crds --version "$CHART_VERSION" \
+ --values "/tmp/camunda-platform-$CHART_VERSION/camunda-platform/openshift/values.yaml"
+ ```
-You can customize the values by providing your own values in addition to the OpenShift values file.
+ You can customize the values by providing your own values in addition to the OpenShift values file.
-
-
+
+
### With permissive SCCs
To use permissive SCCs, simply install the charts as they are. Follow the [general Helm deployment guide](/self-managed/setup/install.md).
-
+
## Available Configurations of OpenShift Components
@@ -221,165 +228,166 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
1. Configure your Zeebe Gateway Ingress to create a [Re-encrypt Route](https://docs.openshift.com/container-platform/latest/networking/routes/route-configuration.html#nw-ingress-creating-a-route-via-an-ingress_route-configuration):
-```yaml
-zeebeGateway:
- ingress:
- grpc:
- annotations:
- route.openshift.io/termination: reencrypt
- route.openshift.io/destination-ca-certificate-secret: camunda-platform-internal-service-certificate
- className: openshift-default
- tls:
- enabled: true
- secretName: camunda-platform-external-certificate
-```
+ ```yaml
+ zeebeGateway:
+ ingress:
+ grpc:
+ annotations:
+ route.openshift.io/termination: reencrypt
+ route.openshift.io/destination-ca-certificate-secret: camunda-platform-internal-service-certificate
+ className: openshift-default
+ tls:
+ enabled: true
+ secretName: camunda-platform-external-certificate
+ ```
-3. Mount the **Service Certificate Secret** to the Zeebe Gateway Pod:
+1. Mount the **Service Certificate Secret** to the Zeebe Gateway Pod:
-```yaml
-zeebeGateway:
- env:
- - name: ZEEBE_GATEWAY_SECURITY_ENABLED
- value: "true"
- - name: ZEEBE_GATEWAY_SECURITY_CERTIFICATECHAINPATH
- value: /usr/local/zeebe/config/tls.crt
- - name: ZEEBE_GATEWAY_SECURITY_PRIVATEKEYPATH
- value: /usr/local/zeebe/config/tls.key
- extraVolumeMounts:
- - name: certificate
- mountPath: /usr/local/zeebe/config/tls.crt
- subPath: tls.crt
- - name: key
- mountPath: /usr/local/zeebe/config/tls.key
- subPath: tls.key
- extraVolumes:
- - name: certificate
- secret:
- secretName: camunda-platform-internal-service-certificate
- items:
- - key: tls.crt
- path: tls.crt
- defaultMode: 420
- - name: key
- secret:
- secretName: camunda-platform-internal-service-certificate
- items:
- - key: tls.key
- path: tls.key
- defaultMode: 420
-```
+ ```yaml
+ zeebeGateway:
+ env:
+ - name: ZEEBE_GATEWAY_SECURITY_ENABLED
+ value: "true"
+ - name: ZEEBE_GATEWAY_SECURITY_CERTIFICATECHAINPATH
+ value: /usr/local/zeebe/config/tls.crt
+ - name: ZEEBE_GATEWAY_SECURITY_PRIVATEKEYPATH
+ value: /usr/local/zeebe/config/tls.key
+ extraVolumeMounts:
+ - name: certificate
+ mountPath: /usr/local/zeebe/config/tls.crt
+ subPath: tls.crt
+ - name: key
+ mountPath: /usr/local/zeebe/config/tls.key
+ subPath: tls.key
+ extraVolumes:
+ - name: certificate
+ secret:
+ secretName: camunda-platform-internal-service-certificate
+ items:
+ - key: tls.crt
+ path: tls.crt
+ defaultMode: 420
+ - name: key
+ secret:
+ secretName: camunda-platform-internal-service-certificate
+ items:
+ - key: tls.key
+ path: tls.key
+ defaultMode: 420
+ ```
-4. Mount the **Service Certificate Secret** to the Operate and Tasklist pods and configure the secure TLS connection. Here, only the `tls.crt` file is required.
+1. Mount the **Service Certificate Secret** to the Operate and Tasklist pods and configure the secure TLS connection. Here, only the `tls.crt` file is required.
-For Operate:
+ For Operate:
-```yaml
-operate:
- env:
- - name: CAMUNDA_OPERATE_ZEEBE_SECURE
- value: "true"
- - name: CAMUNDA_OPERATE_ZEEBE_CERTIFICATEPATH
- value: /usr/local/operate/config/tls.crt
- - name: CAMUNDA_OPERATE_ZEEBE_BROKERCONTACTPOINT
- value: camunda-zeebe-gateway.camunda.svc.cluster.local:26500
- extraVolumeMounts:
- - name: certificate
- mountPath: /usr/local/operate/config/tls.crt
- subPath: tls.crt
- extraVolumes:
- - name: certificate
- secret:
- secretName: camunda-platform-internal-service-certificate
- items:
- - key: tls.crt
- path: tls.crt
- defaultMode: 420
-```
+ ```yaml
+ operate:
+ env:
+ - name: CAMUNDA_OPERATE_ZEEBE_SECURE
+ value: "true"
+ - name: CAMUNDA_OPERATE_ZEEBE_CERTIFICATEPATH
+ value: /usr/local/operate/config/tls.crt
+ - name: CAMUNDA_OPERATE_ZEEBE_BROKERCONTACTPOINT
+ value: camunda-zeebe-gateway.camunda.svc.cluster.local:26500
+ extraVolumeMounts:
+ - name: certificate
+ mountPath: /usr/local/operate/config/tls.crt
+ subPath: tls.crt
+ extraVolumes:
+ - name: certificate
+ secret:
+ secretName: camunda-platform-internal-service-certificate
+ items:
+ - key: tls.crt
+ path: tls.crt
+ defaultMode: 420
+ ```
-The actual configuration properties can be reviewed [in the Operate configuration documentation](/self-managed/operate-deployment/operate-configuration.md#zeebe-broker-connection).
+ The actual configuration properties can be reviewed [in the Operate configuration documentation](/self-managed/operate-deployment/operate-configuration.md#zeebe-broker-connection).
-For Tasklist:
+ For Tasklist:
-```yaml
-tasklist:
- env:
- - name: CAMUNDA_TASKLIST_ZEEBE_SECURE
- value: "true"
- - name: CAMUNDA_TASKLIST_ZEEBE_CERTIFICATEPATH
- value: /usr/local/tasklist/config/tls.crt
- - name: CAMUNDA_TASKLIST_ZEEBE_BROKERCONTACTPOINT
- value: camunda-zeebe-gateway.camunda.svc.cluster.local:26500
- extraVolumeMounts:
- - name: certificate
- mountPath: /usr/local/tasklist/config/tls.crt
- subPath: tls.crt
- extraVolumes:
- - name: certificate
- secret:
- secretName: camunda-platform-internal-service-certificate
- items:
- - key: tls.crt
- path: tls.crt
- defaultMode: 420
-```
+ ```yaml
+ tasklist:
+ env:
+ - name: CAMUNDA_TASKLIST_ZEEBE_SECURE
+ value: "true"
+ - name: CAMUNDA_TASKLIST_ZEEBE_CERTIFICATEPATH
+ value: /usr/local/tasklist/config/tls.crt
+ - name: CAMUNDA_TASKLIST_ZEEBE_BROKERCONTACTPOINT
+ value: camunda-zeebe-gateway.camunda.svc.cluster.local:26500
+ extraVolumeMounts:
+ - name: certificate
+ mountPath: /usr/local/tasklist/config/tls.crt
+ subPath: tls.crt
+ extraVolumes:
+ - name: certificate
+ secret:
+ secretName: camunda-platform-internal-service-certificate
+ items:
+ - key: tls.crt
+ path: tls.crt
+ defaultMode: 420
+ ```
+
+ The actual configuration properties can be reviewed [in the Tasklist configuration documentation](/self-managed/tasklist-deployment/tasklist-configuration.md#zeebe-broker-connection).
-The actual configuration properties can be reviewed [in the Tasklist configuration documentation](/self-managed/tasklist-deployment/tasklist-configuration.md#zeebe-broker-connection).
+1. For Connectors:
-5. For Connectors:
:::note
-The following will no longer be required when [the Connectors component supports PKCS #1 and PKCS #8](https://github.com/camunda/connectors/issues/2806).
+ The following will no longer be required when [the Connectors component supports PKCS #1 and PKCS #8](https://github.com/camunda/connectors/issues/2806).
-:::
+ :::
-The Connectors component only accepts a `jks` (Java KeyStore) certificate.
-If you have followed our previous recommendation of generating a TLS certificate using the OpenShift annotation, you will have a `PKCS #1` certificate the Connectors component will not accept.
-
-Below are a number of commands that convert the `PKCS #1` certificate generated by OpenShift to a `jks` format the Connectors component accepts:
-
-```bash
-# Grab OpenShift generated TLS certificate.
-kubectl get secret -n camunda camunda-zeebe-gateway -o jsonpath="{.data['tls\.crt']}" | base64 --decode > tls.crt
-# Grab OpenShift generated TLS key.
-kubectl get secret -n camunda camunda-zeebe-gateway -o jsonpath="{.data['tls\.key']}" | base64 --decode > zeebe-key.key
-# Convert Zeebe Gateway unencrypted TLS key to an encrypted key. You will be prompted to enter a password when running this command. Note down the password:
-openssl pkcs8 -topk8 -inform PEM -outform PEM -in ./zeebe-key.key -out ./zeebe-encrypted-key-gen.pem -v2 des3
-# Convert PKCS #1 certificate to PKCS #12. Again, you will be prompted to enter the password.
-openssl pkcs12 -export -in tls.crt -inkey zeebe-encrypted-key-gen.pem -out zeebe-p12-certificate.p12 -name "certificate"
-# Convert PKCS #12 certificate to jks cert.
-keytool -importkeystore -srckeystore zeebe-p12-certificate.p12 -srcstoretype pkcs12 -destkeystore keystore.jks
-```
+ The Connectors component only accepts a `jks` (Java KeyStore) certificate.
+ If you have followed our previous recommendation of generating a TLS certificate using the OpenShift annotation, you will have a `PKCS #1` certificate the Connectors component will not accept.
-Create a generic TLS secret from the `jks` file:
+ Below are a number of commands that convert the `PKCS #1` certificate generated by OpenShift to a `jks` format the Connectors component accepts:
-```bash
-kubectl create secret generic keystore -n camunda --from-file keystore.jks
-```
+ ```bash
+ # Grab OpenShift generated TLS certificate.
+ kubectl get secret -n camunda camunda-zeebe-gateway -o jsonpath="{.data['tls\.crt']}" | base64 --decode > tls.crt
+ # Grab OpenShift generated TLS key.
+ kubectl get secret -n camunda camunda-zeebe-gateway -o jsonpath="{.data['tls\.key']}" | base64 --decode > zeebe-key.key
+ # Convert Zeebe Gateway unencrypted TLS key to an encrypted key. You will be prompted to enter a password when running this command. Note down the password:
+ openssl pkcs8 -topk8 -inform PEM -outform PEM -in ./zeebe-key.key -out ./zeebe-encrypted-key-gen.pem -v2 des3
+ # Convert PKCS #1 certificate to PKCS #12. Again, you will be prompted to enter the password.
+ openssl pkcs12 -export -in tls.crt -inkey zeebe-encrypted-key-gen.pem -out zeebe-p12-certificate.p12 -name "certificate"
+ # Convert PKCS #12 certificate to jks cert.
+ keytool -importkeystore -srckeystore zeebe-p12-certificate.p12 -srcstoretype pkcs12 -destkeystore keystore.jks
+ ```
-Once the secret is created, follow the below example `values.yaml` config:
+ Create a generic TLS secret from the `jks` file:
-```yaml
-connectors:
- inbound:
- mode: oauth
- env:
- - name: ZEEBE_CLIENT_BROKER_GATEWAY-ADDRESS
- value: "camunda-zeebe-gateway.camunda.svc.cluster.local:26500"
- - name: ZEEBE_CLIENT_SECURITY_PLAINTEXT
- value: "false"
- - name: JAVA_TOOL_OPTIONS
- value: "-Djavax.net.ssl.trustStore=/usr/local/certificates/keystore.jks -Djavax.net.ssl.trustStorePassword=changeit"
- extraVolumeMounts:
- - name: keystore
- readOnly: true
- mountPath: /usr/local/certificates
- extraVolumes:
- - name: keystore
- secret:
- secretName: keystore
-```
+ ```bash
+ kubectl create secret generic keystore -n camunda --from-file keystore.jks
+ ```
+
+ Once the secret is created, follow the below example `values.yaml` config:
+
+ ```yaml
+ connectors:
+ inbound:
+ mode: oauth
+ env:
+ - name: ZEEBE_CLIENT_BROKER_GATEWAY-ADDRESS
+ value: "camunda-zeebe-gateway.camunda.svc.cluster.local:26500"
+ - name: ZEEBE_CLIENT_SECURITY_PLAINTEXT
+ value: "false"
+ - name: JAVA_TOOL_OPTIONS
+ value: "-Djavax.net.ssl.trustStore=/usr/local/certificates/keystore.jks -Djavax.net.ssl.trustStorePassword=changeit"
+ extraVolumeMounts:
+ - name: keystore
+ readOnly: true
+ mountPath: /usr/local/certificates
+ extraVolumes:
+ - name: keystore
+ secret:
+ secretName: keystore
+ ```
-6. Configure all other applications running inside the cluster and connecting to the Zeebe Gateway to also use TLS.
+1. Configure all other applications running inside the cluster and connecting to the Zeebe Gateway to also use TLS.
diff --git a/versioned_docs/version-8.5/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.5/self-managed/setup/deploy/openshift/redhat-openshift.md
index 5915dfe289..8f413dee14 100644
--- a/versioned_docs/version-8.5/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/versioned_docs/version-8.5/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -9,7 +9,9 @@ import TabItem from '@theme/TabItem';
Red Hat OpenShift, a Kubernetes distribution maintained by [Red Hat](https://www.redhat.com/en/technologies/cloud-computing/openshift), provides options for both managed and on-premise 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)](#security-context-constraints-sccs) and [Routes](./redhat-openshift.md?current-ingress=openshift-routes#using-openshift-routes) configurations might require slight deviations from the guidelines provided in the [general Helm deployment guide](/self-managed/setup/install.md).
+:::
## Cluster Specification
@@ -23,14 +25,16 @@ When deploying Camunda 8 on an OpenShift cluster, the cluster specification shou
We conduct testing and ensure compatibility against the following OpenShift versions:
-- Compatibility is not guaranteed for OpenShift versions no longer supported by Red Hat, as indicated in the "End of Support Date" column.
-
| OpenShift Version | [End of Support Date](https://access.redhat.com/support/policy/updates/openshift) |
| ----------------- | --------------------------------------------------------------------------------- |
+| 4.16.x | December 27, 2025 |
| 4.15.x | August 27, 2025 |
| 4.14.x | May 1, 2025 |
| 4.13.x | November 17, 2024 |
-| 4.12.x | July 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](https://access.redhat.com/support/policy/updates/openshift).
+:::
## Deploying Camunda 8 in OpenShift
@@ -41,35 +45,38 @@ Depending on your OpenShift cluster's Security Context Constraints (SCCs) config
### With restrictive SCCs
-By default, OpenShift employs more restrictive SCCs. The Helm chart must assign `null` to the user running all components and dependencies. Due to a [null bug](https://github.com/helm/helm/issues/9136) [in Helm](https://github.com/helm/helm/issues/12490), this operation must be executed using [a post-renderer](https://helm.sh/docs/topics/advanced/#post-rendering).
+By default, OpenShift employs more restrictive SCCs.
-To deploy Camunda 8 on OpenShift, please follow these installation steps:
+- The Helm chart must assign `null` to the user running all components and dependencies.
+- Due to a [null bug](https://github.com/helm/helm/issues/9136) [in Helm](https://github.com/helm/helm/issues/12490), this operation must be executed using [a post-renderer](https://helm.sh/docs/topics/advanced/#post-rendering).
+
+To deploy Camunda 8 on OpenShift:
1. Install [Helm and other CLI tools](/self-managed/setup/install.md#prerequisites).
-2. Ensure that `bash` and `sed` on linux or `gsed` on mac are available locally, as they are necessary for the post-rendering process to patch the values of OpenShift
+2. Ensure that `bash` and `sed` on linux or `gsed` on mac are available locally, as they are necessary for the post-rendering process to patch the values of OpenShift.
3. Install the [Camunda Helm chart repository](/self-managed/setup/install.md#helm-repository).
-4. Download the exact version of the chart that you want to install and extract it in a directory ([Camunda 8 Helm Chart Version Matrix](https://helm.camunda.io/camunda-platform/version-matrix/)):
+4. Download the exact version of the chart you want to install and extract it in a directory ([Camunda 8 Helm Chart Version Matrix](https://helm.camunda.io/camunda-platform/version-matrix/)):
-```shell
-# List of available versions: https://helm.camunda.io/camunda-platform/version-matrix/
-export CHART_VERSION=""
+ ```shell
+ # List of available versions: https://helm.camunda.io/camunda-platform/version-matrix/
+ export CHART_VERSION=""
-# Make sure to set CHART_VERSION to match the chart version you want to install.
-helm pull camunda/camunda-platform --version "$CHART_VERSION" --untar --untardir "/tmp/camunda-platform-$CHART_VERSION"
-```
+ # Make sure to set CHART_VERSION to match the chart version you want to install.
+ helm pull camunda/camunda-platform --version "$CHART_VERSION" --untar --untardir "/tmp/camunda-platform-$CHART_VERSION"
+ ```
5. Install the Camunda chart with the patched SCCs (`/tmp/camunda-platform-CHART_VERSION/camunda-platform/openshift/values.yaml`) and the post-renderer script (`/tmp/camunda-platform-CHART_VERSION/camunda-platform/openshift/patch.sh`):
-```shell
-helm install camunda camunda/camunda-platform --skip-crds --version "$CHART_VERSION" \
- --values "/tmp/camunda-platform-$CHART_VERSION/camunda-platform/openshift/values.yaml" \
- --post-renderer bash --post-renderer-args "/tmp/camunda-platform-$CHART_VERSION/camunda-platform/openshift/patch.sh"
-```
+ ```shell
+ helm install camunda camunda/camunda-platform --skip-crds --version "$CHART_VERSION" \
+ --values "/tmp/camunda-platform-$CHART_VERSION/camunda-platform/openshift/values.yaml" \
+ --post-renderer bash --post-renderer-args "/tmp/camunda-platform-$CHART_VERSION/camunda-platform/openshift/patch.sh"
+ ```
-You can customize the values by providing your own values in addition to the OpenShift values file.
+ You can customize the values by providing your own values in addition to the OpenShift values file.
-:::note Always use the post-renderer
-For updates as well as the initial installation. Skipping it will reapply default values and may prevent some services from starting.
+:::note important
+Always use the post-renderer for updates as well as the initial installation. Skipping it will reapply default values and may prevent some services from starting.
:::
@@ -227,165 +234,166 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
1. Configure your Zeebe Gateway Ingress to create a [Re-encrypt Route](https://docs.openshift.com/container-platform/latest/networking/routes/route-configuration.html#nw-ingress-creating-a-route-via-an-ingress_route-configuration):
-```yaml
-zeebeGateway:
- ingress:
- grpc:
- annotations:
- route.openshift.io/termination: reencrypt
- route.openshift.io/destination-ca-certificate-secret: camunda-platform-internal-service-certificate
- className: openshift-default
- tls:
- enabled: true
- secretName: camunda-platform-external-certificate
-```
+ ```yaml
+ zeebeGateway:
+ ingress:
+ grpc:
+ annotations:
+ route.openshift.io/termination: reencrypt
+ route.openshift.io/destination-ca-certificate-secret: camunda-platform-internal-service-certificate
+ className: openshift-default
+ tls:
+ enabled: true
+ secretName: camunda-platform-external-certificate
+ ```
-3. Mount the **Service Certificate Secret** to the Zeebe Gateway Pod:
+1. Mount the **Service Certificate Secret** to the Zeebe Gateway Pod:
-```yaml
-zeebeGateway:
- env:
- - name: ZEEBE_GATEWAY_SECURITY_ENABLED
- value: "true"
- - name: ZEEBE_GATEWAY_SECURITY_CERTIFICATECHAINPATH
- value: /usr/local/zeebe/config/tls.crt
- - name: ZEEBE_GATEWAY_SECURITY_PRIVATEKEYPATH
- value: /usr/local/zeebe/config/tls.key
- extraVolumeMounts:
- - name: certificate
- mountPath: /usr/local/zeebe/config/tls.crt
- subPath: tls.crt
- - name: key
- mountPath: /usr/local/zeebe/config/tls.key
- subPath: tls.key
- extraVolumes:
- - name: certificate
- secret:
- secretName: camunda-platform-internal-service-certificate
- items:
- - key: tls.crt
- path: tls.crt
- defaultMode: 420
- - name: key
- secret:
- secretName: camunda-platform-internal-service-certificate
- items:
- - key: tls.key
- path: tls.key
- defaultMode: 420
-```
+ ```yaml
+ zeebeGateway:
+ env:
+ - name: ZEEBE_GATEWAY_SECURITY_ENABLED
+ value: "true"
+ - name: ZEEBE_GATEWAY_SECURITY_CERTIFICATECHAINPATH
+ value: /usr/local/zeebe/config/tls.crt
+ - name: ZEEBE_GATEWAY_SECURITY_PRIVATEKEYPATH
+ value: /usr/local/zeebe/config/tls.key
+ extraVolumeMounts:
+ - name: certificate
+ mountPath: /usr/local/zeebe/config/tls.crt
+ subPath: tls.crt
+ - name: key
+ mountPath: /usr/local/zeebe/config/tls.key
+ subPath: tls.key
+ extraVolumes:
+ - name: certificate
+ secret:
+ secretName: camunda-platform-internal-service-certificate
+ items:
+ - key: tls.crt
+ path: tls.crt
+ defaultMode: 420
+ - name: key
+ secret:
+ secretName: camunda-platform-internal-service-certificate
+ items:
+ - key: tls.key
+ path: tls.key
+ defaultMode: 420
+ ```
-4. Mount the **Service Certificate Secret** to the Operate and Tasklist pods and configure the secure TLS connection. Here, only the `tls.crt` file is required.
+1. Mount the **Service Certificate Secret** to the Operate and Tasklist pods and configure the secure TLS connection. Here, only the `tls.crt` file is required.
-For Operate:
+ For Operate:
-```yaml
-operate:
- env:
- - name: CAMUNDA_OPERATE_ZEEBE_SECURE
- value: "true"
- - name: CAMUNDA_OPERATE_ZEEBE_CERTIFICATEPATH
- value: /usr/local/operate/config/tls.crt
- - name: CAMUNDA_OPERATE_ZEEBE_BROKERCONTACTPOINT
- value: camunda-zeebe-gateway.camunda.svc.cluster.local:26500
- extraVolumeMounts:
- - name: certificate
- mountPath: /usr/local/operate/config/tls.crt
- subPath: tls.crt
- extraVolumes:
- - name: certificate
- secret:
- secretName: camunda-platform-internal-service-certificate
- items:
- - key: tls.crt
- path: tls.crt
- defaultMode: 420
-```
+ ```yaml
+ operate:
+ env:
+ - name: CAMUNDA_OPERATE_ZEEBE_SECURE
+ value: "true"
+ - name: CAMUNDA_OPERATE_ZEEBE_CERTIFICATEPATH
+ value: /usr/local/operate/config/tls.crt
+ - name: CAMUNDA_OPERATE_ZEEBE_BROKERCONTACTPOINT
+ value: camunda-zeebe-gateway.camunda.svc.cluster.local:26500
+ extraVolumeMounts:
+ - name: certificate
+ mountPath: /usr/local/operate/config/tls.crt
+ subPath: tls.crt
+ extraVolumes:
+ - name: certificate
+ secret:
+ secretName: camunda-platform-internal-service-certificate
+ items:
+ - key: tls.crt
+ path: tls.crt
+ defaultMode: 420
+ ```
-The actual configuration properties can be reviewed [in the Operate configuration documentation](/self-managed/operate-deployment/operate-configuration.md#zeebe-broker-connection).
+ The actual configuration properties can be reviewed [in the Operate configuration documentation](/self-managed/operate-deployment/operate-configuration.md#zeebe-broker-connection).
-For Tasklist:
+ For Tasklist:
-```yaml
-tasklist:
- env:
- - name: CAMUNDA_TASKLIST_ZEEBE_SECURE
- value: "true"
- - name: CAMUNDA_TASKLIST_ZEEBE_CERTIFICATEPATH
- value: /usr/local/tasklist/config/tls.crt
- - name: CAMUNDA_TASKLIST_ZEEBE_BROKERCONTACTPOINT
- value: camunda-zeebe-gateway.camunda.svc.cluster.local:26500
- extraVolumeMounts:
- - name: certificate
- mountPath: /usr/local/tasklist/config/tls.crt
- subPath: tls.crt
- extraVolumes:
- - name: certificate
- secret:
- secretName: camunda-platform-internal-service-certificate
- items:
- - key: tls.crt
- path: tls.crt
- defaultMode: 420
-```
+ ```yaml
+ tasklist:
+ env:
+ - name: CAMUNDA_TASKLIST_ZEEBE_SECURE
+ value: "true"
+ - name: CAMUNDA_TASKLIST_ZEEBE_CERTIFICATEPATH
+ value: /usr/local/tasklist/config/tls.crt
+ - name: CAMUNDA_TASKLIST_ZEEBE_BROKERCONTACTPOINT
+ value: camunda-zeebe-gateway.camunda.svc.cluster.local:26500
+ extraVolumeMounts:
+ - name: certificate
+ mountPath: /usr/local/tasklist/config/tls.crt
+ subPath: tls.crt
+ extraVolumes:
+ - name: certificate
+ secret:
+ secretName: camunda-platform-internal-service-certificate
+ items:
+ - key: tls.crt
+ path: tls.crt
+ defaultMode: 420
+ ```
-The actual configuration properties can be reviewed [in the Tasklist configuration documentation](/self-managed/tasklist-deployment/tasklist-configuration.md#zeebe-broker-connection).
+ The actual configuration properties can be reviewed [in the Tasklist configuration documentation](/self-managed/tasklist-deployment/tasklist-configuration.md#zeebe-broker-connection).
+
+1. For Connectors:
-5. For Connectors:
:::note
-The following will no longer be required when [the Connectors component supports PKCS #1 and PKCS #8](https://github.com/camunda/connectors/issues/2806).
+ The following will no longer be required when [the Connectors component supports PKCS #1 and PKCS #8](https://github.com/camunda/connectors/issues/2806).
-:::
+ :::
-The Connectors component only accepts a `jks` (Java KeyStore) certificate.
-If you have followed our previous recommendation of generating a TLS certificate using the OpenShift annotation, you will have a `PKCS #1` certificate the Connectors component will not accept.
-
-Below are a number of commands that convert the `PKCS #1` certificate generated by OpenShift to a `jks` format the Connectors component accepts:
-
-```bash
-# Grab OpenShift generated TLS certificate.
-kubectl get secret -n camunda camunda-zeebe-gateway -o jsonpath="{.data['tls\.crt']}" | base64 --decode > tls.crt
-# Grab OpenShift generated TLS key.
-kubectl get secret -n camunda camunda-zeebe-gateway -o jsonpath="{.data['tls\.key']}" | base64 --decode > zeebe-key.key
-# Convert Zeebe Gateway unencrypted TLS key to an encrypted key. You will be prompted to enter a password when running this command. Note down the password:
-openssl pkcs8 -topk8 -inform PEM -outform PEM -in ./zeebe-key.key -out ./zeebe-encrypted-key-gen.pem -v2 des3
-# Convert PKCS #1 certificate to PKCS #12. Again, you will be prompted to enter the password.
-openssl pkcs12 -export -in tls.crt -inkey zeebe-encrypted-key-gen.pem -out zeebe-p12-certificate.p12 -name "certificate"
-# Convert PKCS #12 certificate to jks cert.
-keytool -importkeystore -srckeystore zeebe-p12-certificate.p12 -srcstoretype pkcs12 -destkeystore keystore.jks
-```
+ The Connectors component only accepts a `jks` (Java KeyStore) certificate.
+ If you have followed our previous recommendation of generating a TLS certificate using the OpenShift annotation, you will have a `PKCS #1` certificate the Connectors component will not accept.
-Create a generic TLS secret from the `jks` file:
+ Below are a number of commands that convert the `PKCS #1` certificate generated by OpenShift to a `jks` format the Connectors component accepts:
-```bash
-kubectl create secret generic keystore -n camunda --from-file keystore.jks
-```
+ ```bash
+ # Grab OpenShift generated TLS certificate.
+ kubectl get secret -n camunda camunda-zeebe-gateway -o jsonpath="{.data['tls\.crt']}" | base64 --decode > tls.crt
+ # Grab OpenShift generated TLS key.
+ kubectl get secret -n camunda camunda-zeebe-gateway -o jsonpath="{.data['tls\.key']}" | base64 --decode > zeebe-key.key
+ # Convert Zeebe Gateway unencrypted TLS key to an encrypted key. You will be prompted to enter a password when running this command. Note down the password:
+ openssl pkcs8 -topk8 -inform PEM -outform PEM -in ./zeebe-key.key -out ./zeebe-encrypted-key-gen.pem -v2 des3
+ # Convert PKCS #1 certificate to PKCS #12. Again, you will be prompted to enter the password.
+ openssl pkcs12 -export -in tls.crt -inkey zeebe-encrypted-key-gen.pem -out zeebe-p12-certificate.p12 -name "certificate"
+ # Convert PKCS #12 certificate to jks cert.
+ keytool -importkeystore -srckeystore zeebe-p12-certificate.p12 -srcstoretype pkcs12 -destkeystore keystore.jks
+ ```
-Once the secret is created, follow the below example `values.yaml` config:
+ Create a generic TLS secret from the `jks` file:
-```yaml
-connectors:
- inbound:
- mode: oauth
- env:
- - name: ZEEBE_CLIENT_BROKER_GATEWAY-ADDRESS
- value: "camunda-zeebe-gateway.camunda.svc.cluster.local:26500"
- - name: ZEEBE_CLIENT_SECURITY_PLAINTEXT
- value: "false"
- - name: JAVA_TOOL_OPTIONS
- value: "-Djavax.net.ssl.trustStore=/usr/local/certificates/keystore.jks -Djavax.net.ssl.trustStorePassword=changeit"
- extraVolumeMounts:
- - name: keystore
- readOnly: true
- mountPath: /usr/local/certificates
- extraVolumes:
- - name: keystore
- secret:
- secretName: keystore
-```
+ ```bash
+ kubectl create secret generic keystore -n camunda --from-file keystore.jks
+ ```
+
+ Once the secret is created, follow the below example `values.yaml` config:
+
+ ```yaml
+ connectors:
+ inbound:
+ mode: oauth
+ env:
+ - name: ZEEBE_CLIENT_BROKER_GATEWAY-ADDRESS
+ value: "camunda-zeebe-gateway.camunda.svc.cluster.local:26500"
+ - name: ZEEBE_CLIENT_SECURITY_PLAINTEXT
+ value: "false"
+ - name: JAVA_TOOL_OPTIONS
+ value: "-Djavax.net.ssl.trustStore=/usr/local/certificates/keystore.jks -Djavax.net.ssl.trustStorePassword=changeit"
+ extraVolumeMounts:
+ - name: keystore
+ readOnly: true
+ mountPath: /usr/local/certificates
+ extraVolumes:
+ - name: keystore
+ secret:
+ secretName: keystore
+ ```
-6. Configure all other applications running inside the cluster and connecting to the Zeebe Gateway to also use TLS.
+1. Configure all other applications running inside the cluster and connecting to the Zeebe Gateway to also use TLS.