trait/route: Add tests for route trait and read certificate from secrets (1.6 branch)

deploy/traits.yaml

@@ -820,8 +820,17 @@ traits:
   platform: false
   profiles:
   - OpenShift
-  description: The Route trait can be used to configure the creation of OpenShift
-    routes for the integration.
+  description: 'The Route trait can be used to configure the creation of OpenShift
+    routes for the integration. The certificate and key contents may be sourced either
+    from the local filesystem or in a Openshift `secret` object. The user may use
+    the parameters ending in `-secret` (example: `tls-certificate-secret`) to reference
+    a certificate stored in a `secret`. Parameters ending in `-secret` have higher
+    priorities and in case the same route parameter is set, for example: `tls-key-secret`
+    and `tls-key`, then `tls-key-secret` is used. The recommended approach to set
+    the key and certificates is to use `secrets` to store their contents and use the
+    following parameters to reference them: `tls-certificate-secret`, `tls-key-secret`,
+    `tls-ca-certificate-secret`, `tls-destination-ca-certificate-secret` See the examples
+    section at the end of this page to see the setup options.'
   properties:
   - name: enabled
     type: bool
@@ -833,19 +842,40 @@ traits:
   - name: tls-termination
     type: string
     description: The TLS termination type, like `edge`, `passthrough` or `reencrypt`.Refer
-      to the OpenShift documentation for additional information.
+      to the OpenShift route documentation for additional information.
   - name: tls-certificate
     type: string
-    description: The TLS certificate contents.Refer to the OpenShift documentation
+    description: The TLS certificate contents.Refer to the OpenShift route documentation
       for additional information.
+  - name: tls-certificate-secret
+    type: string
+    description: The secret name and key reference to the TLS certificate. The format
+      is "secret-name[/key-name]", the value represents the secret name, if there
+      is only one key in the secret it will be read, otherwise you can set a key name
+      separated with a "/".Refer to the OpenShift route documentation for additional
+      information.
   - name: tls-key
     type: string
-    description: The TLS certificate key contents.Refer to the OpenShift documentation
+    description: The TLS certificate key contents.Refer to the OpenShift route documentation
       for additional information.
+  - name: tls-key-secret
+    type: string
+    description: The secret name and key reference to the TLS certificate key. The
+      format is "secret-name[/key-name]", the value represents the secret name, if
+      there is only one key in the secret it will be read, otherwise you can set a
+      key name separated with a "/".Refer to the OpenShift route documentation for
+      additional information.
   - name: tls-ca-certificate
     type: string
-    description: The TLS cert authority certificate contents.Refer to the OpenShift
-      documentation for additional information.
+    description: The TLS CA certificate contents.Refer to the OpenShift route documentation
+      for additional information.
+  - name: tls-ca-certificate-secret
+    type: string
+    description: The secret name and key reference to the TLS CA certificate. The
+      format is "secret-name[/key-name]", the value represents the secret name, if
+      there is only one key in the secret it will be read, otherwise you can set a
+      key name separated with a "/".Refer to the OpenShift route documentation for
+      additional information.
   - name: tls-destination-ca-certificate
     type: string
     description: The destination CA certificate provides the contents of the ca certificate
@@ -854,11 +884,19 @@ traits:
       connection.If this field is not specified, the router may provide its own destination
       CA and perform hostname validation usingthe short service name (service.namespace.svc),
       which allows infrastructure generated certificates to automaticallyverify.Refer
-      to the OpenShift documentation for additional information.
+      to the OpenShift route documentation for additional information.
+  - name: tls-destination-ca-certificate-secret
+    type: string
+    description: The secret name and key reference to the destination CA certificate.
+      The format is "secret-name[/key-name]", the value represents the secret name,
+      if there is only one key in the secret it will be read, otherwise you can set
+      a key name separated with a "/".Refer to the OpenShift route documentation for
+      additional information.
   - name: tls-insecure-edge-termination-policy
     type: string
     description: To configure how to deal with insecure traffic, e.g. `Allow`, `Disable`
-      or `Redirect` traffic.Refer to the OpenShift documentation for additional information.
+      or `Redirect` traffic.Refer to the OpenShift route documentation for additional
+      information.
 - name: service-binding
   platform: false
   profiles:

docs/modules/traits/pages/route.adoc

@@ -3,6 +3,14 @@
 // Start of autogenerated code - DO NOT EDIT! (description)
 The Route trait can be used to configure the creation of OpenShift routes for the integration.
 
+The certificate and key contents may be sourced either from the local filesystem or in a Openshift `secret` object.
+The user may use the parameters ending in `-secret` (example: `tls-certificate-secret`) to reference a certificate stored in a `secret`.
+Parameters ending in `-secret` have higher priorities and in case the same route parameter is set, for example: `tls-key-secret` and `tls-key`,
+then `tls-key-secret` is used.
+The recommended approach to set the key and certificates is to use `secrets` to store their contents and use the
+following parameters to reference them: `tls-certificate-secret`, `tls-key-secret`, `tls-ca-certificate-secret`, `tls-destination-ca-certificate-secret`
+See the examples section at the end of this page to see the setup options.
+
 
 This trait is available in the following profiles: **OpenShift**.
 
@@ -33,25 +41,43 @@ The following configuration options are available:
 | string
 | The TLS termination type, like `edge`, `passthrough` or `reencrypt`.
 
-Refer to the OpenShift documentation for additional information.
+Refer to the OpenShift route documentation for additional information.
 
 | route.tls-certificate
 | string
 | The TLS certificate contents.
 
-Refer to the OpenShift documentation for additional information.
+Refer to the OpenShift route documentation for additional information.
+
+| route.tls-certificate-secret
+| string
+| The secret name and key reference to the TLS certificate. The format is "secret-name[/key-name]", the value represents the secret name, if there is only one key in the secret it will be read, otherwise you can set a key name separated with a "/".
+
+Refer to the OpenShift route documentation for additional information.
 
 | route.tls-key
 | string
 | The TLS certificate key contents.
 
-Refer to the OpenShift documentation for additional information.
+Refer to the OpenShift route documentation for additional information.
+
+| route.tls-key-secret
+| string
+| The secret name and key reference to the TLS certificate key. The format is "secret-name[/key-name]", the value represents the secret name, if there is only one key in the secret it will be read, otherwise you can set a key name separated with a "/".
+
+Refer to the OpenShift route documentation for additional information.
 
 | route.tls-ca-certificate
 | string
-| The TLS cert authority certificate contents.
+| The TLS CA certificate contents.
 
-Refer to the OpenShift documentation for additional information.
+Refer to the OpenShift route documentation for additional information.
+
+| route.tls-ca-certificate-secret
+| string
+| The secret name and key reference to the TLS CA certificate. The format is "secret-name[/key-name]", the value represents the secret name, if there is only one key in the secret it will be read, otherwise you can set a key name separated with a "/".
+
+Refer to the OpenShift route documentation for additional information.
 
 | route.tls-destination-ca-certificate
 | string
@@ -61,14 +87,71 @@ If this field is not specified, the router may provide its own destination CA an
 the short service name (service.namespace.svc), which allows infrastructure generated certificates to automatically
 verify.
 
-Refer to the OpenShift documentation for additional information.
+Refer to the OpenShift route documentation for additional information.
+
+| route.tls-destination-ca-certificate-secret
+| string
+| The secret name and key reference to the destination CA certificate. The format is "secret-name[/key-name]", the value represents the secret name, if there is only one key in the secret it will be read, otherwise you can set a key name separated with a "/".
+
+Refer to the OpenShift route documentation for additional information.
 
 | route.tls-insecure-edge-termination-policy
 | string
 | To configure how to deal with insecure traffic, e.g. `Allow`, `Disable` or `Redirect` traffic.
 
-Refer to the OpenShift documentation for additional information.
+Refer to the OpenShift route documentation for additional information.
 
 |===
 
 // End of autogenerated code - DO NOT EDIT! (configuration)
+
+== Examples
+
+These examples uses *secrets* to store the certificates and keys to be referenced in the integrations. Read Openshift route documentation for detailed information about routes. The https://github.com/apache/camel-k/blob/main/examples/http/PlatformHttpServer.java[PlatformHttpServer.java] is the integration example. 
+
+As a requirement to run these examples, you should have a `secret` with a key and certificate.
+
+=== Generate a self-signed certificate and create a secret
+
+[source,console]
+openssl genrsa -out tls.key
+openssl req -new -key tls.key -out csr.csr -subj "/CN=my-server.com"
+openssl x509 -req -in csr.csr -signkey tls.key -out tls.crt
+oc create secret tls my-combined-certs --key=tls.key  --cert=tls.crt
+
+=== Making an HTTP request to the route
+
+For all examples, you can use the following curl command to make an HTTP request. It makes use of inline scripts to retrieve the openshift namespace and cluster base domain, if you are using a shell which doesn't support these inline scripts, you should replace the inline scripts with the values of your actual namespace and base domain.
+
+[source,console]
+curl -k https://platform-http-server-`oc config view --minify -o 'jsonpath={..namespace}'`.`oc get dnses/cluster -ojsonpath='{.spec.baseDomain}'`/hello?name=Camel-K
+
+* To add an *edge* route using secrets, use the parameters ending in `-secret` to set the secret name which contains the certificate. This route example trait references a secret named `my-combined-certs` which contains two keys named `tls.key` and `tls.crt`.
++
+[source,console]
+kamel run --dev PlatformHttpServer.java -t route.tls-termination=edge -t route.tls-certificate-secret=my-combined-certs/tls.crt -t route.tls-key-secret=my-combined-certs/tls.key
+
+* To add a *passthrough* route using secrets, the TLS is setup in the integration pod, the keys and certificates should be visible in the running integration pod, to achieve this we are using the `--resource` kamel parameter to mount the secret in the integration pod, then we use some camel quarkus parameters to reference these certificate files in the running pod, they start with `-p quarkus.http.ssl.certificate`. This route example trait references a secret named `my-combined-certs` which contains two keys named `tls.key` and `tls.crt`.
++
+[source,console]
+kamel run --dev PlatformHttpServer.java --resource secret:my-combined-certs@/etc/ssl/my-combined-certs -p quarkus.http.ssl.certificate.file=/etc/ssl/my-combined-certs/tls.crt -p quarkus.http.ssl.certificate.key-file=/etc/ssl/my-combined-certs/tls.key -t route.tls-termination=passthrough -t container.port=8443
+
+* To add a *reencrypt* route using secrets, the TLS is setup in the integration pod, the keys and certificates should be visible in the running integration pod, to achieve this we are using the `--resource` kamel parameter to mount the secret in the integration pod, then we use some camel quarkus parameters to reference these certificate files in the running pod, they start with `-p quarkus.http.ssl.certificate`. This route example trait references a secret named `my-combined-certs` which contains two keys named `tls.key` and `tls.crt`.
++
+[source,console]
+kamel run --dev PlatformHttpServer.java --resource secret:my-combined-certs@/etc/ssl/my-combined-certs  -p quarkus.http.ssl.certificate.file=/etc/ssl/my-combined-certs/tls.crt -p quarkus.http.ssl.certificate.key-file=/etc/ssl/my-combined-certs/tls.key -t route.tls-termination=reencrypt -t route.tls-destination-ca-certificate-secret=my-combined-certs/tls.crt -t route.tls-certificate-secret=my-combined-certs/tls.crt -t route.tls-key-secret=my-combined-certs/tls.key -t container.port=8443
+
+* To add a *reencrypt* route using a specific certificate from a secret for the route and https://docs.openshift.com/container-platform/4.8/security/certificates/service-serving-certificate.html#add-service-certificate_service-serving-certificate[Openshift service serving certificates] for the integration endpoint. This way the Openshift service serving certificates is set up only in the integration pod. The keys and certificates should be visible in the running integration pod, to achieve this we are using the `--resource` kamel parameter to mount the secret in the integration pod, then we use some camel quarkus parameters to reference these certificate files in the running pod, they start with `-p quarkus.http.ssl.certificate`. This route example trait references a secret named `my-combined-certs` which contains two keys named `tls.key` and `tls.crt`.
++
+[source,console]
+kamel run --dev PlatformHttpServer.java --resource secret:cert-from-openshift@/etc/ssl/cert-from-openshift  -p quarkus.http.ssl.certificate.file=/etc/ssl/cert-from-openshift/tls.crt -p quarkus.http.ssl.certificate.key-file=/etc/ssl/cert-from-openshift/tls.key -t route.tls-termination=reencrypt -t route.tls-certificate-secret=my-combined-certs/tls.crt -t route.tls-key-secret=my-combined-certs/tls.key -t container.port=8443
++
+Then you should annotate the integration service to inject the Openshift service serving certificates
++
+[source,console]
+oc annotate service platform-http-server service.beta.openshift.io/serving-cert-secret-name=cert-from-openshift
+
+* To add an *edge* route using a certificate and a private key provided from your local filesystem. This example uses inline scripts to read the certificate and private key file contents, then remove all new line characters, (this is required to set the certificate as parameter's values), so the values are in a single line.
++
+[source,console]
+kamel run PlatformHttpServer.java --dev -t route.tls-termination=edge -t route.tls-certificate="$(cat tls.crt|awk 'NF {sub(/\r/, ""); printf "%s\\n",$0;}')" -t route.tls-key="$(cat tls.key|awk 'NF {sub(/\r/, ""); printf "%s\\n",$0;}')"

e2e/common/traits/files/PlatformHttpServer.java

@@ -0,0 +1,25 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *      http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+import org.apache.camel.builder.RouteBuilder;
+
+public class PlatformHttpServer extends RouteBuilder {
+  @Override
+  public void configure() throws Exception {
+    from("platform-http:/hello?httpMethodRestrict=GET").setBody(simple("Hello ${header.name}"));
+  }
+}