-
-
Notifications
You must be signed in to change notification settings - Fork 192
Description
Issue submitter TODO list
- I've searched for an already existing issues here
- I'm running a supported version of the application which is listed here and the feature is not present there
Is your proposal related to a problem?
Imagine you have a team of 30 developers writing data into Kafka, all using the Avro schema. You cannot expect each developer to reconfigure KafkaUI and add the masking data for the newly created columns.
The masking feature as it is can be considered a demo but it is not usable from a practical point of view. But what if the schema metadata would tell you which field is to be masked already?
Describe the feature you're interested in
What we do is asking the developers to define the sensitivity of a field in the schema itself, so for us the Avro definition of a single column looks like (note the __... properties):
{
"name": "CreatedById",
"type": [
"null",
{
"type": "string",
"logicalType": "NVARCHAR",
"length": 100
}
],
"default": null,
"__originalname": "CreatedById",
"__sensitivity": "INTERNAL",
"__internal": false,
"__technical": false,
"__source_data_type": null
},
(We use this library)
The __sensitivity can be e.g. PII for GDPR Personal Identifiable Information, see here for all values.
Now the data masking feature must be configured only once, telling that all fields with __sensitivity not INTERNAL or PUBLIC should be masked.
Describe alternatives you've considered
ACLs help for entire tables but not for fields.
Worse, imagine a dev-test-prod environment. In Prod IT support should still use KafkaUI but the dev KafkaUI settings are not transportable so easy. Also, even in prod now producers can appear/be deployed at any time, without updating the Kafka infrastructure.
Version you're running
8b5494b 7/24/2025, 13:40:05
Additional context
No response