JFR: Scrubbing sensitive information from events

[Erwan Viollet]

Hello,

Here is an example of the types of events we are concerned about:

Recording
│
├── Event (e.g. jdk.InitialSystemProperty)
│     ├── eventType: "jdk.InitialSystemProperty"
│     ├── startTime
│     ├── duration
│     ├── fields:
│     │     ├── key: "javax.net.ssl.keyStorePassword"
│     │     ├── value: "*supersecret*"
│     │     └── ...
│     └── ...
│
├── Event (e.g. jdk.JVMInformation)
│     ├── eventType: "jdk.JVMInformation"
│     ├── jvmArguments: [ "-Xmx4G", "-Djavax.net.ssl.keyStorePassword=
*supersecret*", ... ]
│     └── ...
│
└── ...

The rules are slightly challenging as they need to account for key/value
pairs, arrays and simple fields (like commandLine field).
Here <https://gist.github.com/r1viollet/812ed70c6410c4f62640fd792570d36c>
is a scrub file example. I'm happy to consider ways to simplify this
proposal. Storing JFR files would also be helpful to consider test cases.
Regards,

Erwan


Le mar. 3 juin 2025 à 11:50, Erik Gahlin <erik.gahlin at oracle.com> a écrit :

> We have discussed it, but we don't understand all the details. We are also
> unsure how to best expose it to the end user. Let's say there was a command
> line option -XX:FlightRecorder:scrub-file=<file>.
>
> What would you fill that file with? I want examples that work on real data
> to understand how expressive the filters must be.
>
> Thanks
> Erik
> ------------------------------
> *From:* hotspot-jfr-dev <hotspot-jfr-dev-retn at openjdk.org> on behalf of
> Erwan Viollet <erwan.viollet at gmail.com>
> *Sent:* Monday, June 2, 2025 3:30 PM
> *To:* hotspot-jfr-dev at openjdk.org <hotspot-jfr-dev at openjdk.org>
> *Subject:* JFR: Scrubbing sensitive information from events
>
> Hello,
>
> I am currently looking into how to remove sensitive information from JFR
> events. The main events that typically contain sensitive information:
> jdk.SystemProcess,  jdk.InitialSystemProperty, jdk.JVMInformation.
> Passwords from command lines can typically be found in these events.
>
> Dropping these events altogether is not ideal, as we need them to make
> relevant performance recommendations to users (e.g. suggesting JVM or
> system setting adjustments).
>
> Dropping them or scrubbing them on the backend side (after the fact)
> requires decompressing and re-writing these events, which is wasteful in
> terms of both compute and storage. The approach is not perfect, as we still
> end up intaking and temporarily storing sensitive information.
>
> Ideally, we would like to be able to scrub or redact only the sensitive
> fields within these events (for example, using a simple regex or
> pattern-based rule), rather than dropping the whole event. We also want to
> avoid handling this only after the event has already been written to the
> JFR file, as that does not fully mitigate the risk of exposing sensitive
> data.
>
> At present, it appears there is no public API or supported mechanism to
> intercept or scrub JFR events in-process, before they are persisted. What
> would you think of an API accepting custom scrubbing patterns so that
> sensitive data never leaves the JVM in an unredacted state?
>
> Are there any plans or discussions in this area? I am fairly new to the
> JFR world, so it is likely that I missed previous discussions around this.
>
> Thank you, Best regards,
>
> Erwan Viollet,
>
> Profiling team, Datadog
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-jfr-dev/attachments/20250612/4296c5b7/attachment.htm>