-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Automatic obfuscation/scrubbing of commonly sensitive metadata #2466
Comments
Excellent recommendation and love the idea of privacy-by-default. Should we start with compiling a list of attributes that are likely sensitive? |
Yes -- though unclear the best way to do this. Database queries and URLs come to mind right away. Normalization will also exist in OTel instrumentation libraries at least long term. |
Would it be ideal to introduce a new processor, which would have a default config, which could be overridden through the config file. We could have used attributes processor, however It would be more useful if it supports regex(or some expressions) to specify what we want to filter/scrub. |
I want to point out that this issue is linked in the security-best-practices document but it is currently marked as closed: I consider this quite important for traces and logs, as it's very easy to put the wrong thing in them. |
Is your feature request related to a problem? Please describe.
Sensitive data can exist in telemetry data. For example, the
db.statement
attribute in spans is often deemed as sensitive data. The collector offers ways to address sensitive data (e.g. theattributes
processor), but configuration today is manual.Describe the solution you'd like
It would be desirable for the collector to offer automatic obfuscation/scrubbing automatically for known sensitive metadata. This would eliminate user error, minimize the likelihood of known sensitive data from being exposed and lower the barrier to entry (i.e. domain expertise to know what is sensitive data and how to handle it in the collector).
Describe alternatives you've considered
Continue doing this manually and/or improving documentation
Additional context
One could argue this is dependent on #886 but depends on implementation.
The text was updated successfully, but these errors were encountered: