Secure communication between server, agent and CLI using mTLS

[windsource]

Description

Currently the communication between server and agent via gRPC is unencrypted. In order to provide authentication and encryption mTLS shall be used.

Goals

• The mTLS encryption shall be optional (not required during development)
• A script shall be provided to create CA and certificates
• It shall be documented how to use the generated or existing certificate with Ankaios server and agent
• Server, agent and CLI shall be extended to use mTLS per default (--insecure as extra option)

Tasks

• [x] Check if existing gRPC crate supports mTLS: yes, an example can be found here: I'll also add the link to the description. Some features are not supported (see here ), but they are irrelevant for us
• [x] Extend server and agent with mTLS capabilities (also add command line flags) (don't forget to check the permissions on the files and reject starting if the permissions are too open)
• [x] Provide scripts to generate CA and certs
• [x] Enhance documentation
• [x] Enhance SW design and requirement tracing

[windsource]

The project https://github.com/eclipse/kuksa.val also uses gRPC between client and databroker via TLS so maybe we can check that before.

[christoph-hamm]

I think we should first evaluate if we really need TLS.

• What are the threats?
• Do we need confidentiality or is integrity and authenticity sufficient?
• How dynamic is the system? Is it possible to add Ankaios agents which were unknown when the Ankaios server was set up? (Is public-key encryption necessary or are PSKs sufficient?)
• Is it possible an Ankaios agent, compiled with different parameters but the same API version, connects to the Ankaios server (this would be a reason to use TLS)
• What algorithms are we supporting? Some customer might want to limit the allowed protocols or for legal reasons have to use certain algorithms.

[windsource]

I think we need confidentiality at least for the CLI connecting to the Ankaios server as the CLI might be remote.

[windsource]

Besides using mTLS we could also use TLS + JWT (TLS for encryption + JWT for authentication and authorization). This seems to be simpler plus more flexible.

[krucod3]

As agreed, we first need a concept and we can discuss it together to decide how to proceed.

[windsource]

If this issue is implemented, secure communication shall be on by default. If insecure communication shall be used (e.g. during development or evaluation of Ankaios), a parameter like --insecure needs to be passed or a variable like ANK_INSECURE=true for the CLI should be set.

[krucod3]

As proposed by @christoph-hamm, we can use certificates also for scoping (later if needed) the same way Kubernetes does (via the organization and organizational unit fields).

I looked a bit into what tonic supports. There is an example on how to setup mTLS here: https://github.com/hyperium/tonic/tree/master/examples/src/tls_client_auth and it looks quite straight forward. (I'll also add the link to the description.)

Just a couple of hints:

• From what I see tonic does not support multiple client CAs in parallel (not that we need that).
• Tonic also does not support crl (revocation lists), but we don't need this either.

[krucod3]

Also also should check the permissions of the pem and key files read by server and agent and reject starting if the files are readable by group and others.

[lingnoi]

The PR with the implementation has been reviewed and merged into main.