Automatic obfuscation/scrubbing of commonly sensitive metadata

[flands]

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. the attributes 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.

[gramidt]

Excellent recommendation and love the idea of privacy-by-default. Should we start with compiling a list of attributes that are likely sensitive?

[flands]

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.

[vishalj82]

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.

[BradErz]

I want to point out that this issue is linked in the security-best-practices document but it is currently marked as closed:
https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#scrubbing-sensitive-data

I consider this quite important for traces and logs, as it's very easy to put the wrong thing in them.