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.