Initial JMX authentication foundation #209
Conversation
andrewazores
force-pushed
the
jmx-auth
branch
3 times, most recently
from
41f8047 to
2500246
Compare
Autogenerate credentials for jmxremote.password file used to secure ContainerJFR's own JMX port at image generation time
Entrypoint generates remote JMX password at container startup time to secure ContainerJFR's own incoming connection port
…edentials Support for retrieving credentials from commands or HTTP requests not yet implemented, but this lays the foundation to do so
New default-on JDP discovery replaces need for self-discovery client. Adjust integration tests and entrypoint to suit
There was a problem hiding this comment.
Hey Andrew, sorry for the delay. Looks very good in general, just a few minor comments.
Beyond this, I think we might need something beyond scraping the password from the log for the operator setup. Maybe Container JFR could support credentials generated by the operator via environment variables or something?
src/main/java/com/redhat/rhjmc/containerjfr/net/TargetConnectionManager.java
Outdated
Show resolved
Hide resolved
src/main/java/com/redhat/rhjmc/containerjfr/net/TargetConnectionManager.java
Show resolved
Hide resolved
|
Yea, I wasn't sure what made the most sense from the Operator's POV, but that makes sense. If a password is provided via env var then use that, otherwise generate it as implemented here. Do you have any preference for how that env var is named? |
Maybe just |
Related to #5
See also cryostatio/cryostat-core#42
This PR lays down initial support for connections to targets using JMX access control/authentication. No mechanism for the user to supply JMX credentials is yet implemented, but connections to targets configured with JMX security will now fail with an identifiable exception, including an appropriate HTTP header for HTTP API requests or an appropriate status code for WebSocket API commands. HTTP API support for supplying credentials will be relatively simple - the
AbstractAuthenticatedRequestHandler#getConnectionDescriptorFromContextmethod will simply be updated to check theProxy-Authorizationrequest header for Basic auth credentials to pass on to the target JMX connection. WebSocket API support for optional credentials will require more work (see: #205 for one proposed solution), or perhaps the WebSocket API will simply never gain JMX auth support and all such requests will need to go through the HTTP REST API instead.Additionally, the ContainerJFR container image is now built with a custom entrypoint script, and the entrypoint by default enables JMX access control on the container's own remote JMX port, with an autogenerated password for the default "containerjfr" user. This password can be seen in the ContainerJFR instance's logs at startup time. This authentication (and the password generation) can be disabled for testing/development purposes. The SelfDisoveryPlatformClient is also removed and JDP autodiscovery is enabled instead so that the ContainerJFR instance can use JDP to discover itself within its container in a more uniform manner, providing itself with its own JMXServiceURL and Main-Class name. In environments where JDP autodiscovery is not used, ex. Kubernetes/OpenShift, this also has the net effect of preventing the self-connection list item from appearing in the discovered targets list.