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.

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

[Story] Separate TLS keystore/truststore from host application #138

Closed
5 tasks done
Tracked by #124
andrewazores opened this issue Jun 6, 2023 · 3 comments
Closed
5 tasks done
Tracked by #124
Assignees
Labels
feat New feature or request high-priority

Comments

@andrewazores
Copy link
Member

andrewazores commented Jun 6, 2023

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

@andrewazores andrewazores added feat New feature or request high-priority labels Jun 6, 2023
@andrewazores andrewazores self-assigned this Sep 20, 2023
@andrewazores
Copy link
Member Author

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.

@andrewazores
Copy link
Member Author

@andrewazores
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat New feature or request high-priority
Projects
Status: Done
Status: Stretch Goals
Status: In Progress
Development

No branches or pull requests

2 participants