Open elasticmachine opened 7 years ago
Original comment by @andrewvc:
Can we fix this problem by providing finer grained access control? It seems that the problem is that some people should be able to look at the config, and some people should not be able to.
Wouldn't that solve these users problems more completely?
Original comment by @andrewvc:
Another thought is that even if we did mask conditionals we need to send the ids, and those are usually semantic, which would have the same effect. In other words, you might configure your grok like:
grok {
id => parseMySensitiveFieldName
}
Original comment by @suyograo:
What about an option to turn off the pipeline viewer all together? Is there a way we can not ship the elements for pipeline viewer and then from the UI side we can disable it if we see a flag in the monitoring event?
Original comment by @suyograo:
@bohyun-e brought up a good point today about security concerns around field names in the pipeline viewer. The only place I know that a field name or a config snippet is exposed is in the conditional UI component.
There could be customers who wouldn't want the field names shipped and exposed in the UI to all users. To this end, we should consider adding a granular config option (
xpack.monitoring.mask_field_names: true
) on x-pack-logstash to mask field names when shipping it.I think the shape of the pipeline is still valuable with the masked conditional (at least the user knows there is a fork in the dataflow), so I'd prefer shipping
scrubbed
or some variation of it when this flag is allowed. I'd like to ship some value likescrubbed
rather than skipping it entirely to differentiate this known scenario from any legit bug we have which would cause us to not ship data.Thoughts?
/cc @acchen97 @bohyun-e @ycombinator @andrewvc