backend-*-api: add RedactionsService #24730
Open
+411
−37
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hey, I just made a Pull Request!
I realized that customizing the root logger is kinda tricky right now since it also wires up the secret redactions from config. That and the follow-up for #24478 made me think that it might be worth introducing a redactions service. It both lets plugins add sensitive data to redactions and also lets them do their own redactions for sensitive content. In particular, I'm thinking that both Scaffolder and TechDocs build logs that we stream to the client could use this.
Kept it very simple for now, but there's one problem that might be worth introducing some extra solution for, which is that an ever-growing redactions filter might have a performance impact. A long-running deployment might simply pile up a lot of secrets over time to the point where the RegExp compilation and execution becomes a problem. There's also the potential issue of ReDos attacks if user input is ever forwarded to the redactions by a plugin.
One potential solution is to be able to add a redaction with a TTL, although there's a risk that it only solves the long-running service problem and not the malicious user input. Another option could be the creation of some form of redaction context where secrets can be added only for that particular context, the idea being that this is particularly useful to handle scaffolder user input. That might be a bit overkill for a service though, and it's possible that we should instead implement local filtering in the scaffolder in addition to using the service.
✔️ Checklist
Signed-off-by
line in the message. (more info)