cryostatio/cryostat-agent

[Story] Separate TLS keystore/truststore from host application

andrewazores opened this issue · 3 comments

The Agent contains an HTTP webserver that exposes its API for Cryostat. This webserver should support HTTPS, and it should be possible to configure the Agent to use a TLS keystore and certificate for securing this HTTPS server. It should be possible for this TLS keystore to be separate from any the attached target application might already have.

The Agent also contains an HTTP client that it uses for communicating with Cryostat, to register itself as a discovery plugin, publsh information about itself, etc. This HTTP client should support HTTPS that the Cryostat server may expose. Likewise, it should be possible to configure the Agent to add the Cryostat server's TLS certificate to the Agent's truststore, and it should be possible to configure it so that this Agent truststore is separate from the truststore of the attached target application.

Related: cryostatio/cryostat-operator#595

Another possibility: generate a certificate in advance, common to all Agent instances. The certificate's domain will be incorrect in this case so the Cryostat server's webclient will need to ignore host verification. This certificate would be bundled as a resource in the Agent JAR as well as included in the Cryostat server's default truststore. This way, the Agent instances can always present an HTTPS API and all data leaving the Agent can always be encrypted with this cert, and the Cryostat server can at least trust this certificate for its Agent webclients, even if it cannot verify the hostname. This way there is a zero-configuration setup that allows HTTPS to be always on for Cryostat<->Agent communications.

In the future this could be extended with a configurable setup that allows the user to supply their own cert as originally outlined at the top of this issue. The Operator could be in charge of supplying this cert to the Agent for it to use for its embedded HTTPS server, and to the Cryostat instance in its truststore. This would allow more granularity so that the certificate is common to all Agents within a given Namespace, rather than all Agent instances indiscriminately.

I think this is actually already completed with @mwangggg's latest work on the Agent truststore/keystore, where those are already independent stores from the global JVM configuration.