The java agent sends many environment settings when connecting to new relic, one of those is the JVM arguments.
It is not unusual for customers to include sensitive information there and we must avoid sending that over the network.
Acceptance Criteria
This is a research spike to analyze they payload sent and determine feasibility to detect any sensitive data and exclude it from the payload in some manner. This may include new relic secrets, like a license key, but also other secrets the client may pass as a jvm argument to their applications like credentials to access cloud services, DB credentials, etc.
After the completion of the spike, we'll want to discuss findings with the requesting org before proceeding.
Design Consideration/Limitations
Since it's likely to be difficult to reliably detect and remove only sensitive data, this has the potential of obscuring settings that are valuable for the customer to see, so this should be agent configurable (will need to determine whether to default on or off)
May want to consider either an allow or block list to be specified, to make it easier to leave common JVM parameters alone
Should discuss with other agent teams to determine whether an agent spec should be considered
This might obscure data that is helpful for support purposes; we'll want to understand that possible impact
Dependencies
The connect service team is taking a look at something similar, as a short-term implementation. We should sync up with them to understand where they are. JVM property key values by frequency, that may not contain sensitive values:
Description
The java agent sends many environment settings when connecting to new relic, one of those is the JVM arguments.
It is not unusual for customers to include sensitive information there and we must avoid sending that over the network.
Acceptance Criteria
This is a research spike to analyze they payload sent and determine feasibility to detect any sensitive data and exclude it from the payload in some manner. This may include new relic secrets, like a license key, but also other secrets the client may pass as a jvm argument to their applications like credentials to access cloud services, DB credentials, etc.
After the completion of the spike, we'll want to discuss findings with the requesting org before proceeding.
Design Consideration/Limitations
on
oroff
)allow
orblock
list to be specified, to make it easier to leave common JVM parameters aloneDependencies
The
connect
service team is taking a look at something similar, as a short-term implementation. We should sync up with them to understand where they are. JVM property key values by frequency, that may not contain sensitive values:Examples where JVM parameters might contain sensitive values:
Additional context
Original work request - NR-295685