In most probability, it will be Kibana not sending basic auth header. I would suggest that you set verbosity to error and turn on the audit collector to true. ROR will create its own daily index. That will be easier to query and visualize later on.
In our case, like I have mentioned in above posts, we ended up setting up read-only rule on monitoring index, with IP list and xforwarded rule.
Also check if .Kibana is on your list of allowed auto create index list. You might want to include ReadonlyREST also in that list.
Glad to help. I already spent several weeks breaking my head for not getting monitoring to work, until we figured out this work around. I don’t want anyone else to be wasting time on this You wouldn’t believe, if I told you that the Kibana issue has been open in their repo for nearly a year now. Also just be aware that currently ROR daily indexes stays forever, until in some future release auto cleanup gets added as a feature, timelines of it, only Simone or one of the contributors will be able to comment on.
@sscarduzio, given that the Kibana fix is not going to come anytime soon, why not put it under official documentation, under troubleshooting section for setting up Kibana with monitoring.
Next on my list in coming weeks is to setup separate monitoring cluster using xpack forwarders feature. Need to see if that works on basic xpack license and ROR combination. Will post some updates, once that setup is complete or you might hear sooner, if I run into issues.
Yes the audit log rotation is coming! What should be the default sliding window size? 1 week? Suggestions accepted.
About putting the monitoring stuff in the documentation: my friend, of all of us, you are the best person to add this info in our new open source documentation project!
@sscarduzio for audit log rotation, I can think of 2 approach.
First one is where you give the frequency setting option upfront - which decides the frequency of index creation - daily, weekly, monthly, quarterly and a second setting that controls when to clean up the indexes.
Second option is continue with creating daily indexes, but give option to delete them after n days (I would suggest default to 15 days) and also give option to consolidate the indexes into weekly, monthly, quarterly. For people who are using ES purely for log analytics, storing historical security audit logs might not be a big requirement. So they might want regular clean up. But for those who are using ES for storing/searching some sensitive data, historical audit logs will still be a need. So instead of continuing with just daily indexes, its better to consolidate the indexes as part of the clean up process, which means whenever you delete the index, you also copy the data into one of the consolidated index.
I will look at updating the documentation in the coming week or two
The most important thing is that the audit log is stored in the index. All other rotation related maintenance can be easily adopted/expanded with Curator’s help
Yes. Curator can be used for that purpose. But now that becomes an additional task that each and everyone using ROR will need to build, test and manage themselves independently. So having it built out of the box in ROR makes more sense to me.
Only difference now is that list of default indices that Elastic/Kibana looks under monitoring has increased. If you are using version 6, you will probably just see the v6 indices in the FORBIDDEN list. Process to identify the indices list is same as before. Enable ROR auditing and check which requests are being blocked, when you launch monitoring, so that you are verify specific, when setting this rule.
You wouldn’t believe, if I told you that the Kibana issue has been open in their repo for nearly a year now. Also just be aware that currently ROR daily indexes stays forever, until in some future release auto cleanup gets added as a feature, timelines of it, only Simone or one of the contributors will be able to comment on.
