Fleet-server cannot write to a fleet managed index

Elastic Stack Elastic Agent
1

I created a custom ingest pipeline (logs-system.security@custom) that looks for event ID 5152 or 5157 in the Windows security log, and redirects those events to the iptables indexes (logs-iptables.log-default), after modifying some fields to conform with the constraints of the iptables index schema. The reasons aren't important, but if you must know this would be so different ILM policies could be applied to firewall events vs. security logs events.

I figured since this was a fleet managed index there wouldn't be any problem writing to it. Wrong. Ended up with these errors:

action [indices:data/write/bulk[s]] is unauthorized for API key id [redacted] of user [elastic/fleet-server] on indices [.ds-logs-iptables.log-default-2022.11.03-000002,.ds-logs-iptables.log-default-2022.11.03-000004,logs-iptables.log-default], this action is granted by the index privileges [create_doc,create,delete,index,write,all]"}, dropping event!

After a few hours of banging my head against a wall trying to figure out why the fleet-server account couldn't write to an index that it apparently has access to (since the iptables integration in a Linux specific policy works just fine) I decided to add the iptables integration to the Windows specific policy. Suddenly the errors disappeared and the data was being written to logs-iptables.log-default as expected.

This isn't just an issue with the iptables integration. If the " Collect logs from System instances" option is not selected for a Windows machine the agent cannot write to the logs-system.auth-default index, which seems like the logical place to put authentication events from a Windows machine. Again, the reason would be for different ILM policies for authentication logs.

So this brings up a couple questions

  1. Does each agent policy get an API key that can only write to the indexes/data streams that are being used within that policy?
  2. If so what are the drawbacks of using a single agent policy that contains integrations that aren't used on some systems, or aren't even applicable for the operating system - like the iptables integration on a Windows machine?

Thanks

2

I can't think of any drawbacks of approach 2.
From your description it looks like indeed the agent policy's API key is limited to its integrations, though I haven't found info about this in our docs.

3

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.