P3
Enhance JDK Flight Recorder (JFR) to automatically redact sensitive data, such as tokens and passwords, from key event fields before they are written to a recording.
Current approaches to data redaction require removing or disabling entire JFR events, making it difficult to retain useful context while avoiding recording secrets. Relying on filtering after the fact provides no guarantee that sensitive data did not reach disk or get forwarded elsewhere. The JVM must not be a vehicle for inadvertently exposing or distributing sensitive data from the shell, which includes credentials, tokens, or secrets set via environment variables, system properties, or the command line.
Before environment variables, system properties, and command line arguments are recorded by JFR, their keys will be checked against a default set of glob patterns. For example, any variable named API_TOKEN, dbPassword, or jwt_secret would match patterns like *token*, *password*, or *secret*. If a match is found, the value is replaced by a redacted marker such as ***.
By default, patterns such as *password*, *token*, and *secret* are enabled to catch common cases. Users may further refine or extend these filters as needed using command-line options:
$ java -XX:StartFlightRecording -XX:FlightRecorderOptions:redaction-filter=token*,password ...
To completely disable in-process redaction and record data unfiltered, users can specify:
$ java -XX:StartFlightRecording -XX:FlightRecorderOptions:redaction-filter=none ...
The redaction applies only to selected sensitive fields, preserving other diagnostic content in JFR recordings.
The jfr scrub command offers post-processing redaction by removing whole events or fields from existing recordings. However, this approach is cumbersome and risks exposing sensitive information before scrubbing and may unnecessarily discard useful diagnostics. Excluding events outright also results in significant loss of observability.
Current approaches to data redaction require removing or disabling entire JFR events, making it difficult to retain useful context while avoiding recording secrets. Relying on filtering after the fact provides no guarantee that sensitive data did not reach disk or get forwarded elsewhere. The JVM must not be a vehicle for inadvertently exposing or distributing sensitive data from the shell, which includes credentials, tokens, or secrets set via environment variables, system properties, or the command line.
Before environment variables, system properties, and command line arguments are recorded by JFR, their keys will be checked against a default set of glob patterns. For example, any variable named API_TOKEN, dbPassword, or jwt_secret would match patterns like *token*, *password*, or *secret*. If a match is found, the value is replaced by a redacted marker such as ***.
By default, patterns such as *password*, *token*, and *secret* are enabled to catch common cases. Users may further refine or extend these filters as needed using command-line options:
$ java -XX:StartFlightRecording -XX:FlightRecorderOptions:redaction-filter=token*,password ...
To completely disable in-process redaction and record data unfiltered, users can specify:
$ java -XX:StartFlightRecording -XX:FlightRecorderOptions:redaction-filter=none ...
The redaction applies only to selected sensitive fields, preserving other diagnostic content in JFR recordings.
The jfr scrub command offers post-processing redaction by removing whole events or fields from existing recordings. However, this approach is cumbersome and risks exposing sensitive information before scrubbing and may unnecessarily discard useful diagnostics. Excluding events outright also results in significant loss of observability.