Our email logs can be pretty sensitive, especially since they include our corporate emails passing through (senders, recipients, timestamps etc.).

So, I'm a bit concerned about both whether our access controls are sufficient, and also whether the security of this platform is good enough to protect us against privilege escalation attacks.

Is this something that has been considered already? I'm not objecting this per se -- I'd just like for this to be carefully planned and reviewed because of the sensitivity of this particular log stream :)

That makes sense, and likely applies to other types of logs as well. It seems to me like something worth solving in the ELK stack.

Do we have an X-Pack subscription from elastic? If so we could use that to configure role based acls and segment access to various types of logs based on ldap group membership natively in Elasticsearch and Kibana.

If not, another potential approach is to...

• Ship this type of sensitive log to an index prefix that is outside the scope of the currently configured Kibana search prefix.
• Restrict the ability of users to modify the Kibana index prefix setting via the web interface.
• Stand up a "root only" Kibana instance with strict authorization (require cn=ops,ou=groups,dc=wikimedia,dc=org or such) that is configured to search across both root and non-root indices.

Today we have Logstash outputting to Elasticsearch indices prefixed with logstash- and Kibana is configured to query logstash-*. We could change the prefix something like logstash-all- for unprivileged logs, and logstash-root- for "root only" logs.

IIRC each Kibana instance has it's own ES index for config storage, meaning visualizations, dashboards, etc would not kept in sync between two instances with differing search prefix configs. So that's a compromise to think about when separating log access this way. Maybe there's a way around it. Worst case these could be exported/imported between instances.