Auditing deleted indexes

[splunkzilla]

I have been asked to alert when a user deletes an index.  

I have found the event in the _internal index, but there is no username attached to the event.

index=_internal event=removeIndex

05-13-2024 21:57:01.509 +0000 INFO IndexProcessor [1036423 indexerPipe_1] - event=removeIndex index=deleteme is newly marked for deletion, avoided restart

There does not appear to be a corresponding event in the _audit index, so I'm drawing a blank on how to attribute the event to a user account.

The solution provided here doesn't appear to work, as I'm not seeing an operations or object field in the _audit index. 

[jotne]

Only admin should be allowed and able to remove indexes.  You should have controll of who that is.

[PickleRick]

It depends on your architecture and what you mean by "user deleted an index".

What user would you want to associate with deleting an index by means of editing indexes.conf and restarting splunkd? And in a cluster scenario when the entry is deleted from indexes.conf and pushed to indexers?

I suppose you're talking about an all-in-one installation and assume all admin operations are done via GUI. You'd have to look for requests from the browser to the appropriate section of the settings page.

[splunkzilla]

Sorry about that, I should have been more clear.

We are using Splunk Cloud, so we would be looking for index deletions via the Web GUI (Settings-->Indexes-->Actions-->Delete).  I can see the removeIndex action being taken in the _internal index - ideally there would be a log linking the index deletion to the user account.  Do we really need to pull in browser request data in order to audit actions that occur within Splunk?  Sorry if I'm missing something here.

[PickleRick]

I'm not a Cloud guru but still index removal as such is done by expediting the request from the search-head layer to the indexers (you do not see this as the customer/user in the Cloud but it's happening under the hood).

So the actual removal which you are finding in _internal is one thing but it is triggered by something. And for this something you should look for in _audit index.

In an on-premise installation you get:

Audit:[timestamp=05-16-2024 10:25:24.161, user=admin, action=indexes_edit, info=granted object="deletetest" operation=remove]

 I suppose you should get something similar in Cloud as well.

So look for

index=_audit action=indexes_edit operation=remove