Security issues of using beats_system

[vbohata]

I see a big security issue of using beats_system for monitoring beats shippers. It uses the same privilege (cluster:admin/xpack/monitoring/bulk) as logstash for its monitoring and probably allows the beats to send an arbitrary monitoring data. For components managed by Elastic administrator like Elasticsearch/Kibana/Logstash/beats on the es/kb/ls servers it if fine. But in larger deployments (like our) the beats are also managed by different departments/some 3rd party developers etc. If beats monitoring is being used in these deployments, it allows everyone who has access to some of monitored beats logshippers to break the whole monitoring because:

1. Each monitoring beats shipper contains credentials of user having beats_system (cluster:admin/xpack/monitoring/bulk) privilege
2. Everyone can use these credentials to put an arbitrary data to the Elasticsearch to destroy/fake monitoring data of any other component (beats shippers, logstash, elasticsearch monitored node ...)

In small or medium deployments this security flaw is more theoretical as the breaching probability is low but in large deployments (hundereds of log shippers located on-premise, in clouds, ...) it creates a very serious security issue.

So there should be more granular permissions and checking of each of the connected beats. This has to be done on elasticsearch side. Or on the beats side the solution can be more simple if it could route monitoring data via logstash as a regular shipped logs. Currently in our deployments we use 2 additional fields in beats shippers - machine_group, authkey. On the logstash side we check if the pair is correct. This is very simple and effective, could be also usable if beats would allow to route its monitoring data via logstash.

[elasticmachine]

Pinging @elastic/es-security