Hi! This is Jeff Saxe, long-standing customer, and I actually had a problem vaguely similar to this back a couple of years ago, but I found a proper solution then. This looks like a different issue, but it still feels like a bug to me.
I just upgraded our cluster from 8.6.1 w/ RoR 1.47 to now 8.19 w/ RoR 1.66. Mostly things are working, but I have a few specific indices that we want to prevent our internal users from seeing (firewall logs and other confidential items), so I have a few RoR rules that say “if you’re trying to read these index wildcard-patterned names, and you’re not a member of this group, then FORBID”. These used to be written in terms of two consecutive rules – first, ALLOW if you ARE a member of the group and trying to look at these indices; then FORBID if you are trying to look at these indices and you passed by that first rule, so obviously you’re not in the group. But now, with the new “groups_not_any_of” statement, I can simplify it to one rule.
Anyway, with either the old or the new group-membership syntax, it seems to be false-triggering on this FORBID rule when my users are just trying to bring up a nice Dashboard, in particular a Dashboard that already worked before this upgrade and which has absolutely nothing to do with the special named confidential indices! Even just bringing up the list of Dashboards from the left nav bar, even that is triggering the FORBID rule, so they can’t see the list! The entries in the Elasticsearch log are quite long and I would need to sanitize them of internal IP addresses and names and such, but basically, I can see that it’s falling through the first few rules, and when it hits this rule
- name: "Deny unauthorized to firewall logs"
ldap_auth:
name: "ourLDAPdomain"
groups_not_any_of: [ "ElasticsearchSensitiveFirewallLogs" ]
indices: ["sensitivelogs-*"]
actions: ["indices:data/read/*"]
type: forbid
then the rule is matching, and it even seems to expand out the wildcard of the “sensitivelogs-2025.08.23, sensitivelogs-2025.10.03” etc. index names, just to prove to me that it’s justified in giving the FORBIDDEN result. But the dashboard in question is based on other, non-sensitive index names, and of course the choice list of Dashboards isn’t even based on any index names at all, until the user chooses a particular one to view.
If the user uses the Discovery tab, then everything is fine and security works as expected. They are able to view any collection of non-sensitive logs they like, and if they choose a sensitive-log collection, it gives them no data on the timeline. Awesome. So Discovery is not broken, only Dashboard access attempts seem to be broken. None of this happened in the previous version (before the upgrade).
Am I imagining things? What do you need from our side to troubleshoot the issue? If you want log excerpts, I’m happy to email them privately, just perhaps not posted here in the forum. Thanks in advance!
– Jeff Saxe, Quantitative Investment Management, Charlottesville, VA