Skip to content

feat: wildcard json unmasking#2555

Open
mscabbiolo-gfm wants to merge 5 commits intotchiotludo:devfrom
mscabbiolo-gfm:feat-wildcard-json-unmasking
Open

feat: wildcard json unmasking#2555
mscabbiolo-gfm wants to merge 5 commits intotchiotludo:devfrom
mscabbiolo-gfm:feat-wildcard-json-unmasking

Conversation

@mscabbiolo-gfm
Copy link

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.

@jamfor999
Copy link
Contributor

jamfor999 commented Jan 5, 2026

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.

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.
The idea behind the implementation is that it should take effort to unmask fields in a production deployment. I would ask whether you really need to unmask all the fields in a topic to begin with

Not saying this shouldn't go in, but I would recommend this to be gated by another toggleable flag like enable-wildcards: true which should be false by default, with a comment explaining this risk above enabling it (and in the documentation, too, as this might not be an obvious risk at first). At the very least this would be an explicit "I am fully aware and opting into understanding this risk" rather than just enabling it.

(note: This risk obviously doesn't apply to unmask by default, but does for mask by default)

@mscabbiolo-gfm
Copy link
Author

@jamfor999 I share your concern, we have a proper review process in place that should catch any dangerous wildcard additions. Adding an opt-in enable-wildcards sounds fine to me, let me know if its a blocker and I can add it when I have some time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Backlog

Development

Successfully merging this pull request may close these issues.

2 participants