Ah, sorry, I didn’t notice before.
You are trying to write to the “business_logs” index.
- name: "Admins"
groups: [Administrators]
kibana:
access: admin
The “admin” kibana access allows RW access to kibana-related and ROR-related indices only.
I guess, in this use case, we miss the good cause in logs too.
Kibana rule set to “admin” access level is about the user interacting with kibana and being able to crud the dashboards, other kibana objects, settings etc. Not certainly tainting arbitrary indices in elasticsearch.
The product vision in ROR is that the kibana user is a consumer of the data, and ingestion agents and maintenance tasks get authenticated through specialised, independent, pure REST acl blocks (where no kibana rule present).
After almost a decade, kibana feature creep enabled indices maintenance tasks in the kibana gui but that’s a different story.
In this support case, the customer is trying to use credentials associated with a kibana workflow for bulk data ingestion, which is fighting against the ROR data protection semantics.
Perhaps we are doing a bad job at documenting?
I’d you truly want an unrestricted kibana god user, omit the kibana rule or use access level “unrestricted”. The two are identical in function.