-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
[receiver/jmxreceiver] Limit parameters for JMX receiver to reduce security risk #9721
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This LGTM. @rmfitzpatrick do you want to have a look?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for taking this up! Please update the README file as well.
ResourceAttributes map[string]string `mapstructure:"resource_attributes"` | ||
// Log level used by the JMX metric gatherer. Should be one of: | ||
// `"trace"`, `"debug"`, `"info"`, `"warn"`, `"error"`, `"off"` | ||
LogLevel string `mapstructure:"log_level"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any thoughts on whether this should re-use the log level set in the collector's service.logging
setting instead of adding its own?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm open to it. The only drawbacks I see are that there's no Trace equivalent in zap.Level and several levels (fatal, panic, dpanic, error) would probably all map to error (or possibly panic/dpanic to "off").
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@codeboten implemented it so if no user config is provided, it attempts to translate from zap logger level, otherwise it uses the user provided config. Let me know what you think!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 looks good to me
Co-authored-by: Alex Boten <[email protected]>
@codeboten, mind taking another look? |
…curity risk (open-telemetry#9721) * Remove options considered too permissive for security in jmx receiver * Use config file for communicating to JMX metrics gatherer * Fix small issues with jmx receiver * Ensure property files are generated correctly with multiline input * Update changelog * minor changes to receiver to support more config in properties file * Update properties file generation * Address PR feedback and address environment variable attack surface * Update receiver/jmxreceiver/config.go Co-authored-by: Alex Boten <[email protected]>
…curity risk (open-telemetry#9721) * Remove options considered too permissive for security in jmx receiver * Use config file for communicating to JMX metrics gatherer * Fix small issues with jmx receiver * Ensure property files are generated correctly with multiline input * Update changelog * minor changes to receiver to support more config in properties file * Update properties file generation * Address PR feedback and address environment variable attack surface * Update receiver/jmxreceiver/config.go Co-authored-by: Alex Boten <[email protected]>
Description: Update the JMX Receiver as a part of the effort to reduce its attack surface. This PR removes the generic
properties
parameter, removes the ability to use a user-defined groovy script, and communicates with the subprocess via a properties file rather than command line parameters.Link to tracking Issue: #9686 #9685
Testing: Manually validated in addition to updates to the unit tests. Integration tests for JMX receiver are currently flaky and require improvement.