TLS support in KUKSA.val Client

Update tonic

Give warning if insecure not given
Remove server hack

.github/workflows/kuksa-client.yml

@@ -23,7 +23,6 @@ on:
     - "kuksa-client/**"
   workflow_dispatch:
 
-
 jobs:
   checkrights:
     uses: ./.github/workflows/check_push_rights.yml
@@ -95,3 +94,28 @@ jobs:
         push: false
         tags: "ttl.sh/kuksa.val/kuksa-client-${{github.sha}}:1h"
         labels: ${{ steps.meta.outputs.labels }}
+
+
+  dbc2val-test:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout kuksa.val
+        uses: actions/checkout@v3
+      - name: Install pip
+        run: |
+          python -m pip --quiet --no-input install --upgrade pip
+      - name: Install dependencies with pip
+        run: |
+          cd kuksa-client
+          pip install -r requirements.txt -e .
+          pip install -r test-requirements.txt
+      - name: Run tests
+        run: |
+          cd kuksa-client
+          pytest
+      - name: Build pypi package
+        run: |
+          cd kuksa-client
+          pip install --upgrade build
+          python -m build
+

Cargo.toml

@@ -31,7 +31,7 @@ prost-types = "0.11"
 tokio = "1.17.0"
 # tokio-stream has no features
 tokio-stream = "0.1.8"
-tonic = { version = "0.8", default-features = false }
+tonic = { version = "0.9.1", default-features = false }
 tonic-build = { version = "0.8", default-features = false }
 
 [profile.release]

README.md

@@ -28,5 +28,7 @@ KUKSA.val contains several components
 | [Examples](./kuksa_apps) | Multiple example apps for different programming languages and frameworks
 | [Feeders](https://github.com/eclipse/kuksa.val.feeders/) | Multiple feeders to gathering vehicle data and transforming it to VSS suitable for kuksa-val-server
 
+## More information
 
+* [KUKSA.val TLS Concept](doc/tls.md)
 

doc/tls.md

@@ -0,0 +1,112 @@
+# KUKSA.val TLS concept
+
+This page describes the TLS support in KUKSA.val
+
+## Security concept
+
+KUKSA.val supports TLS for connection between KUKSA.val Databroker/Server and clients.
+
+General design concept in short:
+
+* KUKSA.val Server and KUKSA.val Databroker by default only accept TLS connection. Insecure connections can be allowed by a configuration setting
+* Mutual authentication not supported, i.e. KUKSA.val Server and KUKSA.val Databroker does not authenticate clients
+* A set of example certificates and keys exist in the [kuksa_certificates](kuksa_certificates) repository
+* The example certificates are used as default by some applications
+* The example certificates shall only be used during development and re not suitable for production use
+* KUKSA.val does not put any additional requirements on what certificates that are accepted, default settings as defined by OpenSSL and gRPC are typically used
+
+## Example certificates
+
+For more information see the [README.md](kuksa_certificates/README.md).
+
+**NOTE: The example keys and certificates shall not be used in your production environment!  **
+
+## Examples using example certificates
+
+This section intends to give guidelines on how you can verify TLS functionality with KUKSA.val.
+It is based on using the example certificates.
+
+
+## KUKSA.val databroker
+
+KUKSA.val Databroker supports TLS, but not mutual authentication.
+By default (for historical reasons) an insecure connection is used.
+In the future this might be change so that `--insecure` is required to start an insecure connection.
+
+To use a secure connection specify `--tls-cert`and `--tls-private-key`
+
+```
+~/kuksa.val/kuksa_databroker$ cargo run --bin databroker -- --metadata ../data/vss-core/vss_release_4.0.json --tls-cert ../kuksa_certificates/Server.pem --tls-private-key ../kuksa_certificates/Server.key
+```
+
+Default certificates and keys are not included in the default KUKSA.val Databroker container,
+so if running KUKSA.val Databroker from a default container you need to mount the directory containing the keys and certificates.
+
+```
+~/kuksa.val/kuksa_databroker$ docker run --rm -it  -p 55555:55555/tcp -v /home/user/kuksa.val/kuksa_certificates:/certs databroker --tls-cert /certs/Server.pem --tls-private-key /certs/Server.key
+```
+
+## KUKSA.val databroker-cli
+
+Can be run in TLS mode like below.
+Note that [databroker-cli](kuksa_databroker/databroker-cli/src/main.rs) currently expects the certificate
+to have "Server" as subjectAltName.
+
+```
+~/kuksa.val/kuksa_databroker$ cargo run --bin databroker-cli -- --ca-cert ../kuksa_certificates/CA.pem
+```
+
+Default certificates and keys are not included in the default KUKSA.val Databroker-cli container,
+so if running KUKSA.val Databroker-cli from a default container you need to mount the directory containing the keys and certificates.
+
+```
+docker run --rm -it --net=host -v /home/user/kuksa.val/kuksa_certificates:/certs databroker-cli --ca-cert /certs/CA.pem
+```
+
+## KUKSA.val Server
+
+Uses TLS by default, but doe not support mutual TLS. By default it uses KUKSA.val example certificates/keys `Server.key`, `Server.pem` and `CA.pem`.
+
+```
+~/kuksa.val/kuksa-val-server/build/src$ ./kuksa-val-server  --vss ./vss_release_4.0.json
+```
+
+It is posible to specify a different certificate path, but the file names must be the same as listed above.
+
+```
+~/kuksa.val/kuksa-val-server/build/src$ ./kuksa-val-server  --vss ./vss_release_4.0.json -cert-path ../../../kuksa_certificates
+```
+
+In KUKSA.val Server the default certificates and keys are included in the container, so no need to
+mount a directory if you want to use default certificates and keys.
+
+```
+docker run -it --rm -p 127.0.0.1:8090:8090 -e LOG_LEVEL=ALL kuksa-val:latest
+```
+
+If using the default KUKSA.val Server Docker container there is no mechanism to use different certificates,
+as the [Dockerfile](../kuksa-val-server/docker/Dockerfile) specifies that the default shall be used.
+
+## KUKSA.val Client (command line)
+
+See [KUKSA.val Client Documentation](../kuksa-client/README.md).
+
+## KUKSA.val Client (library)
+
+Clients like [KUKSA.val CAN Feeder](https://github.com/eclipse/kuksa.val.feeders/tree/main/dbc2val)
+tht use KUKSA.val Client library must typically set the path to the root CA certificate.
+If the path is set the VSSClient will try to establish a secure connection.
+
+```
+# Shall TLS be used (default False for Databroker, True for KUKSA.val Server)
+# tls = False
+tls = True
+
+# TLS-related settings
+# Path to root CA, needed if using TLS
+root_ca_path=../../kuksa.val/kuksa_certificates/CA.pem
+# Server name, typically only needed if accessing server by IP address like 127.0.0.1
+# and typically only if connection to KUKSA.val Databroker
+# If using KUKSA.val example certificates the names "Server" or "localhost" can be used.
+# tls_server_name=Server
+```

kuksa-client/README.md

@@ -31,9 +31,8 @@ With default CLI arguments, the client will try to connect to a local VISS serve
 If you wish to connect to a gRPC server e.g. `kuksa-databroker`, you should instead run:
 
 ```console
-$ kuksa-client --ip 127.0.0.1 --port 55555 --protocol grpc --insecure
+$ kuksa-client --ip 127.0.0.1 --port 55555 --protocol grpc
 ```
-Note: `--insecure` is required because `kuksa-databroker` does not yet support TLS encryption or authentication.
 
 If everything works as expected and the server can be contacted you will get an output similar to below.
 
@@ -82,12 +81,59 @@ Test Client> authorize /some/path/kuksa_certificates/jwt/super-admin.json.token
 
 If connecting to Databroker the command `printTokenDir` is not much help as it shows the default token directories
 for KUKSA.val Server example tokens. If the KUKSA.val Databroker use default example tokens then one of the
-tokens in [../jwt](..//jwt) can be used, like in the example below:
+tokens in [../jwt](../jwt) can be used, like in the example below:
 
 ```console
-Test Client> authorize /some/path//jwt/provide-all.token
+Test Client> authorize /some/path/jwt/provide-all.token
 ```
 
+## Using TLS
+
+KUKSA.val Client use TLS by default, it only run in insecure mode if `--insecure` is given as argument.
+
+By default the KUKSA.val example Root CA and Client keys are used, but client keys have no effect as mutual authentication is not supported by KUKSA.val Databroker or KUKSA.val Server.
+
+```
+~/kuksa.val/kuksa-client$ kuksa-client --ip localhost --port 55555 --protocol grpc
+```
+
+This call with all parameters specified give same effect:
+
+```
+~/kuksa.val/kuksa-client$ kuksa-client --ip localhost --port 55555 --protocol grpc --certificate ../kuksa_certificates/Client.pem --keyfile ../kuksa_certificates/Client.key --cacertificate ./kuksa_certificates/CA.pem
+```
+
+There is actually no reason to specify client key and certificate, as mutual authentication is not supported in KUKSA.val Databroker,
+so the command can be simplified like this:
+
+
+```
+~/kuksa.val/kuksa-client$ kuksa-client --ip localhost --port 55555 --protocol grpc --cacertificate ./kuksa_certificates/CA.pem
+```
+
+The example server protocol list 127.0.0.1 as an alternative name, but the TLS-client currently used does not accept it,
+instead a valid server name must be given as argument.
+Currently `Server` and `localhost`are valid names from the example certificates.
+
+```
+~/kuksa.val/kuksa-client$ kuksa-client --ip 127.0.0.1 --port 55555 --protocol grpc  --cacertificate ../kuksa_certificates/CA.pem --tls-server-name Server
+```
+
+### Connecting to KUKSA.val Server
+
+Connecting to KUKSA.val Server is default, and TLS is used by default by KUKSA.val Server.
+`--tls-server-name` does not need to be used when connecting to KUKSA.val Server,
+that is the only difference compared to connecting to KUKSA.val Databroker.
+
+```
+~/kuksa.val/kuksa-client$ kuksa-client
+```
+
+This corresponds to this call:
+
+```
+kuksa-client --ip 127.0.0.1 --port 8090 --protocol ws --cacertificate ./kuksa_certificates/CA.pem
+```
 
 ## Usage Instructions
 
@@ -251,6 +297,26 @@ This package holds different APIs depending on your application's requirements.
 For more information, see ([Documentation](https://github.com/eclipse/kuksa.val/blob/master/kuksa-client/docs/main.md)).
 
 
+### TLS configuration
+
+Clients like [KUKSA.val CAN Feeder](https://github.com/eclipse/kuksa.val.feeders/tree/main/dbc2val)
+that use KUKSA.val Client library must typically set the path to the root CA certificate.
+If the path is set the VSSClient will try to establish a secure connection.
+
+```
+# Shall TLS be used (default False for Databroker, True for KUKSA.val Server)
+# tls = False
+tls = True
+
+# TLS-related settings
+# Path to root CA, needed if using TLS
+root_ca_path=../../kuksa.val/kuksa_certificates/CA.pem
+# Server name, typically only needed if accessing server by IP address like 127.0.0.1
+# and typically only if connection to KUKSA.val Databroker
+# If using KUKSA.val example certificates the names "Server" or "localhost" can be used.
+# tls_server_name=Server
+```
+
 ## Troubleshooting
 
 1. The server/data broker is listening on its port but my client is unable to connect to it and returns an error: