Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs(self-managed): update OpenShift routes instructions #3997

Merged
merged 23 commits into from
Jul 23, 2024
Merged

docs(self-managed): update OpenShift routes instructions #3997

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
23 commits
Select commit Hold shift + click to select a range
6c710f6
changes for routes
hamza-m-masood Jun 27, 2024
cf9835b
fix indentation
conceptualshark Jun 27, 2024
29864a0
fixed link
hamza-m-masood Jun 28, 2024
625e71f
added github issue link
hamza-m-masood Jun 28, 2024
1798e4e
fix spelling error
hamza-m-masood Jun 28, 2024
abff907
reword
hamza-m-masood Jun 28, 2024
878d697
reword
hamza-m-masood Jun 28, 2024
a968bac
pkcs
hamza-m-masood Jun 28, 2024
d81b1b6
cert to certificate
hamza-m-masood Jun 28, 2024
8139970
ingress
hamza-m-masood Jun 28, 2024
7a2d969
jks
hamza-m-masood Jun 28, 2024
d8ee383
adding space in pkcs
hamza-m-masood Jun 28, 2024
436fa1d
change ns
hamza-m-masood Jun 28, 2024
87d1ee8
reworded comments
hamza-m-masood Jun 28, 2024
2cd6048
changed placeholders to default names
hamza-m-masood Jun 28, 2024
012ea64
added changes to 8.6
hamza-m-masood Jul 2, 2024
6746f11
added full stops
hamza-m-masood Jul 2, 2024
68ffca6
added in space at start of comments
hamza-m-masood Jul 2, 2024
bbf451a
style(formatting): minor grammatical tweaks
christinaausley Jul 3, 2024
79e7bb0
add space after the commit hash
aabouzaid Jul 3, 2024
8d27b9c
adding back spaces to comments
hamza-m-masood Jul 18, 2024
8dbc2c2
formatting and copyedits
conceptualshark Jul 22, 2024
d4e905c
Merge branch 'main' into routes-modification
conceptualshark Jul 22, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 10 additions & 8 deletions docs/self-managed/setup/deploy/openshift/redhat-openshift.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -193,7 +193,7 @@ To use these routes for the Zeebe Gateway, configure this through Ingress as wel

As the Zeebe Gateway also uses `gRPC` (which relies on `HTTP/2`), [HTTP/2 Ingress Connectivity has to be enabled](https://docs.openshift.com/container-platform/latest/networking/ingress-operator.html#nw-http2-haproxy_configuring-ingress).

Also, Zeebe Gateway should be configured to use an encrypted connection with TLS because in OpenShift the connection from HAProxy to the Zeebe Gateway service can use HTTP/2 only for re-encrypt or passthrough routes and not for edge-terminated or insecure routes.
Additionally, the Zeebe Gateway should be configured to use an encrypted connection with TLS. In OpenShift, the connection from HAProxy to the Zeebe Gateway service can use HTTP/2 only for re-encryption or pass-through routes, and not for edge-terminated or insecure routes.

#### Required Steps

Expand Down Expand Up @@ -332,31 +332,33 @@ The actual configuration properties can be reviewed [in the Tasklist configurati

5. For Connectors:

The Connectors component will only accept a `jks`(Java KeyStore) certificate.
If you have followed our previous recommendation of generating a TLS certificate using the OpenShift annotation, then you will have a `PKCS #1` certificate which the Connectors component will not accept. For convenience, here are a number of commands that will convert the `PKCS #1` certirficate, generated by OpenShift to `jks` format, that Connectors component accepts:
The Connectors component will only accept 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:

```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. Please note down the password:
#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 password.
#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
```

Finally create a generic TLS secret from the jks file:
Create a generic TLS secret from the `jks` file:

```bash
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. There is a [github issue](https://github.com/camunda/connectors/issues/2806) created for this
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, this example values.yaml config can be followed:
Once the secret is created, the following example `values.yaml` config can be followed:

```yaml
connectors:
Expand Down
24 changes: 13 additions & 11 deletions versioned_docs/version-8.5/self-managed/setup/deploy/openshift/redhat-openshift.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -193,7 +193,7 @@ To use these routes for the Zeebe Gateway, configure this through Ingress as wel

As the Zeebe Gateway also uses `gRPC` (which relies on `HTTP/2`), [HTTP/2 Ingress Connectivity has to be enabled](https://docs.openshift.com/container-platform/latest/networking/ingress-operator.html#nw-http2-haproxy_configuring-ingress).

Also, Zeebe Gateway should be configured to use an encrypted connection with TLS because in OpenShift the connection from HAProxy to the Zeebe Gateway service can use HTTP/2 only for re-encrypt or passthrough routes and not for edge-terminated or insecure routes.
Additionally, the Zeebe Gateway should be configured to use an encrypted connection with TLS. In OpenShift, the connection from HAProxy to the Zeebe Gateway service can use HTTP/2 only for re-encryption or pass-through routes, and not for edge-terminated or insecure routes.

#### Required Steps

Expand Down Expand Up @@ -332,31 +332,33 @@ The actual configuration properties can be reviewed [in the Tasklist configurati

5. For Connectors:

The Connectors component will only accept a `jks`(Java KeyStore) certificate.
If you have followed our previous recommendation of generating a TLS certificate using the OpenShift annotation, then you will have a `PKCS #1` certificate which the Connectors component will not accept. For convenience, here are a number of commands that will convert the `PKCS #1` certirficate, generated by OpenShift to `jks` format, that Connectors component accepts:
The Connectors component will only accept 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:

```bash
# Grab OpenShift generated TLS certificate
#Grab OpenShift generated TLS certificate.
kubectl get secret -n camunda camunda-zeebe-gateway -o jsonpath="{.data['tls\.crt']}" | base64 --decode > tls.crt
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed in https://github.com/camunda/distribution/issues/254#issuecomment-2196227345, could we integrate this directly at the startup of the container?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@conceptualshark We continued our discussion and noticed that instead we should put a reference to a github issue in the docs: camunda/connectors#2806

Is it a good idea to put a link to a github issue in the docs or should I just mention that we are working on a fix that will not require this manual workaround and not add a link?

For now I will add a link and you can remove it if you think it's not appropriate.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added link to github issue ✅

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this reference is fine - we can make a note to remove it once the issue is closed.

# Grab OpenShift generated TLS key.
#Grab OpenShift generated TLS key.
christinaausley marked this conversation as resolved.
Show resolved Hide resolved
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. Please note down the password:
#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 password.
#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.
#Convert PKCS #12 certificate to jks cert.
keytool -importkeystore -srckeystore zeebe-p12-certificate.p12 -srcstoretype pkcs12 -destkeystore keystore.jks
```

Finally create a generic TLS secret from the jks file:
Create a generic TLS secret from the `jks` file:

```bash
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. There is a [github issue](https://github.com/camunda/connectors/issues/2806) created for this
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, this example values.yaml config can be followed:
Once the secret is created, the following example `values.yaml` config can be followed:

```yaml
connectors:
Expand Down
Loading