From 8dbc2c279a06d43cf1b1218cc070327cb73451c0 Mon Sep 17 00:00:00 2001 From: Cole Garbo Date: Mon, 22 Jul 2024 11:53:47 -0400 Subject: [PATCH] formatting and copyedits --- .../deploy/openshift/redhat-openshift.md | 22 +++++++++++-------- .../deploy/openshift/redhat-openshift.md | 22 +++++++++++-------- 2 files changed, 26 insertions(+), 18 deletions(-) diff --git a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md index c828237de1..f3470473bf 100644 --- a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md +++ b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md @@ -200,7 +200,8 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect 1. Provide two [TLS secrets](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets) for the Zeebe Gateway. - The first TLS secret is issued to the Zeebe Gateway Service Name. This must use the [PKCS #8 syntax](https://en.wikipedia.org/wiki/PKCS_8) or [PKCS #1 syntax](https://en.wikipedia.org/wiki/PKCS_1) as Zeebe only supports these, referenced as `camunda-platform-internal-service-certificate`. - In the example below, a TLS certificate is generated for the Zeebe Gateway service with an [annotation](https://docs.openshift.com/container-platform/latest/security/certificates/service-serving-certificate.html). The generated certificate will be in the form of a secret. + + In the example below, a TLS certificate is generated for the Zeebe Gateway service with an [annotation](https://docs.openshift.com/container-platform/latest/security/certificates/service-serving-certificate.html). The generated certificate will be in the form of a secret. ```yaml zeebeGateway: @@ -209,7 +210,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect service.beta.openshift.io/serving-cert-secret-name: camunda-platform-internal-service-certificate ``` - Another option would be to use [Cert Manager](https://docs.openshift.com/container-platform/latest/security/cert_manager_operator/index.html). For more details, review the [OpenShift documentation](https://docs.openshift.com/container-platform/latest/networking/routes/secured-routes.html#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes). + Another option is [Cert Manager](https://docs.openshift.com/container-platform/latest/security/cert_manager_operator/index.html). For more details, review the [OpenShift documentation](https://docs.openshift.com/container-platform/latest/networking/routes/secured-routes.html#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes).
PKCS #8, PKCS #1 syntax @@ -222,9 +223,9 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
- - The second TLS secret is used on the exposed route, referenced as `camunda-platform-external-certificate`. For example, this would be the same TLS secret you would use for Ingress. + - The second TLS secret is used on the exposed route, referenced as `camunda-platform-external-certificate`. For example, this would be the same TLS secret used for Ingress. -2. 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): +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: @@ -331,11 +332,16 @@ tasklist: The actual configuration properties can be reviewed [in the Tasklist configuration documentation](/self-managed/tasklist-deployment/tasklist-configuration.md#zeebe-broker-connection). 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 Connectors component will only accept a `jks` (Java KeyStore) certificate. +::: + +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. -For convenience, below are a number of commands that will convert the `PKCS #1` certificate, generated by OpenShift to a `jks` format the Connectors component accepts: +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. @@ -356,9 +362,7 @@ Create a generic TLS secret from the `jks` file: kubectl create secret generic keystore -n camunda --from-file keystore.jks ``` -This workaround will not be required when [the Connectors component supports PKCS #1 and PKCS #8](https://github.com/camunda/connectors/issues/2806). - -Once the secret is created, the following example `values.yaml` config can be followed: +Once the secret is created, follow the below example `values.yaml` config: ```yaml connectors: 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 c828237de1..f3470473bf 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 @@ -200,7 +200,8 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect 1. Provide two [TLS secrets](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets) for the Zeebe Gateway. - The first TLS secret is issued to the Zeebe Gateway Service Name. This must use the [PKCS #8 syntax](https://en.wikipedia.org/wiki/PKCS_8) or [PKCS #1 syntax](https://en.wikipedia.org/wiki/PKCS_1) as Zeebe only supports these, referenced as `camunda-platform-internal-service-certificate`. - In the example below, a TLS certificate is generated for the Zeebe Gateway service with an [annotation](https://docs.openshift.com/container-platform/latest/security/certificates/service-serving-certificate.html). The generated certificate will be in the form of a secret. + + In the example below, a TLS certificate is generated for the Zeebe Gateway service with an [annotation](https://docs.openshift.com/container-platform/latest/security/certificates/service-serving-certificate.html). The generated certificate will be in the form of a secret. ```yaml zeebeGateway: @@ -209,7 +210,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect service.beta.openshift.io/serving-cert-secret-name: camunda-platform-internal-service-certificate ``` - Another option would be to use [Cert Manager](https://docs.openshift.com/container-platform/latest/security/cert_manager_operator/index.html). For more details, review the [OpenShift documentation](https://docs.openshift.com/container-platform/latest/networking/routes/secured-routes.html#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes). + Another option is [Cert Manager](https://docs.openshift.com/container-platform/latest/security/cert_manager_operator/index.html). For more details, review the [OpenShift documentation](https://docs.openshift.com/container-platform/latest/networking/routes/secured-routes.html#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes).
PKCS #8, PKCS #1 syntax @@ -222,9 +223,9 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
- - The second TLS secret is used on the exposed route, referenced as `camunda-platform-external-certificate`. For example, this would be the same TLS secret you would use for Ingress. + - The second TLS secret is used on the exposed route, referenced as `camunda-platform-external-certificate`. For example, this would be the same TLS secret used for Ingress. -2. 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): +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: @@ -331,11 +332,16 @@ tasklist: The actual configuration properties can be reviewed [in the Tasklist configuration documentation](/self-managed/tasklist-deployment/tasklist-configuration.md#zeebe-broker-connection). 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 Connectors component will only accept a `jks` (Java KeyStore) certificate. +::: + +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. -For convenience, below are a number of commands that will convert the `PKCS #1` certificate, generated by OpenShift to a `jks` format the Connectors component accepts: +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. @@ -356,9 +362,7 @@ Create a generic TLS secret from the `jks` file: kubectl create secret generic keystore -n camunda --from-file keystore.jks ``` -This workaround will not be required when [the Connectors component supports PKCS #1 and PKCS #8](https://github.com/camunda/connectors/issues/2806). - -Once the secret is created, the following example `values.yaml` config can be followed: +Once the secret is created, follow the below example `values.yaml` config: ```yaml connectors: