-
Notifications
You must be signed in to change notification settings - Fork 2.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
[processor/redaction] Initial implementation #6495
[processor/redaction] Initial implementation #6495
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jpkrohling have you made an analysis about the difference between this processor and the "attributes" processor? What does this bring more to us? Why do we need two?
# DryRun mode documents the changes the processor would make without | ||
# deleting your data. You can use it to confirm that the right span | ||
# attributes will be redacted | ||
dry_run: false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be achieved by having a "separate" pipeline with only logging/debugging exporter. We don't have this pattern anywhere else because of that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bogdandrutu That makes sense. I've now removed the dry run mode from the PR
The original issue has some considerations about the design choices:
The last part is what convinced me that another processor might make sense, even if only for a better user experience. |
Is the |
Test restarted. |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
@bogdandrutu, should this component be accepted? |
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
@leonsp-ai, could you please go over #6926 and see if this component has what is listed there? The discussion about whether this component would be accepted is also kind of covered there: if you can find an approver to act as sponsor, this would be accepted. |
be007fd
to
87f4df1
Compare
@jpkrohling Sure, I can do that. Finding a sponsor is tricky, as I am someone new entering the community. I'll try reaching out on the CNCF Slack. For the first PR, I worked with @mx-psi and @dmitryax Checklist from #6926:
|
d7f4051
to
2a0ce9f
Compare
@bogdandrutu, should this be accepted? I think we talked about this before and we would accept this one even though the transform processor (or some of its parts) could be reused in a future implementation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One nit, otherwise LGTM
# the processor adds to the spans when it redacts or masks other | ||
# attributes. In some contexts a list of redacted attributes leaks | ||
# information, while it is valuable when integrating and testing a new | ||
# configuration. Possible values are `debug`, `info`, and `silent`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should describe what's the expected behavior for each value
ping @bogdandrutu |
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
@jpkrohling who is the sponsor? who is going to maintain this? Why the "translator" is not good (or this becomes "a function" in that)? |
I thought @mx-psi and @dmitryax were volunteers, but seeing myself on that list as well made me realize that those are not sponsors. @leonsp-ai, were you able to find a sponsor yet?
Not sure I get what you meant here. Are you referring to the attributes processor? Or is it about the new transform processor? |
I trust @dmitryax that this will have a consistent query language as the transform processor
@dmitryax I updated the README with your feedback. cc @jpkrohling |
CI seems to be stuck. And it seems that I can't rebase this to get a new CI build, so, you'd need to rebase this yourself. In the process, please replace my entry in the code owners with @MovieStoreGuy (current code owner in the version from the main branch). |
ee5260d
to
3f6ec91
Compare
Looking back I see @MovieStoreGuy took care of some unowned modules (thank you!), but now that we have some significant contributors to this module I've listed them instead. |
Edit: @william-tran I'm addressing the EasyCLA regression by squashing the previously covered commits Will's moving on to exciting and related new things as of March 18 |
48feb45
to
058dd40
Compare
@leonsp-ai, I appreciate the sentiment, but could you please do the load test changes in a separate PR? Failures on those tests won't prevent this PR from being merged. |
a9d82f4
to
edb9313
Compare
@jpkrohling Sure. I've moved those changes out into #8789 |
- Use actual key names in yaml doc README - fix typo in CHANGELOG.md Co-authored-by: Juraci Paixão Kröhling <[email protected]>
edb9313
to
31c7bf4
Compare
This has been approved a few times already, merging. If there are anything pending, it can be done in a follow-up PR. Thanks! |
Description: Implement a redaction processor to prevent leaking sensitive or private span attributes or span attribute values for privacy, security, and compliance purposes.
Link to tracking Issue: #4131
Testing: Test coverage for redaction processor
Documentation: Updates to the redaction processor readme