feat: wildcard json unmasking#2555
Conversation
Just to add some context behind the original idea (I wrote the code for the current functionality, see #1899 #2004 #2051 ) - I considered adding such a feature but my reason for avoiding it was that it makes production scenarios much more brittle/dangerous - you might think a topic has no Personal Data/Pii in it, then down the line evolve the schema, add a pii field, and forget to update the filter, creating a security issue. Adding a wildcard adds a false sense of security if you believe "oh yeah, this topic definitely will never have pii in it" and then the reality of software engineering compromises might end up unfortunately hitting you, and you forget about this filter in your AKHQ deployment. Not saying this shouldn't go in, but I would recommend this to be gated by another toggleable flag like (note: This risk obviously doesn't apply to unmask by default, but does for mask by default) |
|
@jamfor999 I share your concern, we have a proper review process in place that should catch any dangerous wildcard additions. Adding an opt-in |
Support unmasking whole topics or json paths with wildcard notation. No side effects expected, added tests.
Use case: We are setting up AKHQ masking in a couple of big clusters with a lot of topics on them and a lot of teams working in parallel. Having to set up each individual key can become very cumbersome in some cases and the configuration file hard to manage. Having wildcard matchers will make the whole process easier.