Filter panel doesn't get populated with field values on alias index for non-super user

[bhavyarm]

Kibana version: 7.15.0 , 7.14.1

Elasticsearch version: 7.15.0, 7.14.1

Server OS version: darwin_x86_64

Browser version: chrome latest

Browser OS version: OS X

Original install method (e.g. download page, yum, from source, etc.): from staging

Describe the bug: If a non-super user tries to build a filter using alias fields - Kibana displays empty for field values drop down.
Please note the same filter panel works fine for super user.

This is a regression in 7.14.1. Worked fine in 7.13.4

Alias index:

Empty filter panel:

These are my role details:
GET /_security/role/aliasrole

This bug is the result of a support ticket linked. Please note this doesn't work in 7.15.0 & 7.14.1 but works in 7.13.x. Can we also get some tests along with the fix?

{
  "aliasrole" : {
    "cluster" : [
      "all"
    ],
    "indices" : [
      {
        "names" : [
          "indextest"
        ],
        "privileges" : [
          "all"
        ],
        "field_security" : {
          "grant" : [
            "*"
          ],
          "except" : [ ]
        },
        "allow_restricted_indices" : false
      }
    ],
    "applications" : [
      {
        "application" : "kibana-.kibana",
        "privileges" : [
          "space_all"
        ],
        "resources" : [
          "space:default"
        ]
      }
    ],
    "run_as" : [ ],
    "metadata" : { },
    "transient_metadata" : {
      "enabled" : true
    }
  }
}

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[LeeDr]

Bhavya and I worked on this and figured out that the user needs read and view_index_metadata (or at least one of those) on the index itself, and also on the alias. The expected behavior is that they only need permissions on the alias.

I don't really know if the issue is in Kibana or Elasticsearch. It could be that Kibana is dereferencing the alias to the index name and querying Elasticsearch with the index name? Or that Elasticsearch is checking the user privs on the index instead of the alias?

[bhavyarm]

Please note this works fine if you change Autocomplete value suggestion method in advanced settings to terms_agg from terms_enum (terms_enum is default)

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[rayafratkina]

This seems to be a fairly significant issue on Discover - user may not be able to see what then need in Discover even while they are able to see this data elsewhere (Dev Tools for example).

Security team suggested that we should require administrators to grant both read and view_index_metadata. For a while Discover worked with just read if the index pattern already existed. However now that the field cache is gone from the index pattern/data view, we really require view_index_metadata for Discover to function. Perhaps it's time to make this change?

[mattkime]

Would it be worthwhile to reexamine why view_index_metadata is required in addition to read? I know it has to do with the field caps api and decisions made by the ES team but I really have zero insight into any of it. From a naive perspective, 'read' should mean 'read' full stop.

[timroes]

Removing the Discover labels here. There seems to be no Discover specific details to this (unless I missunderstand the issue)? It's caused by index patterns and the search bar, both owned by app services.

[LeeDr]

Would it be worthwhile to reexamine why view_index_metadata is required in addition to read? I know it has to do with the field caps api and decisions made by the ES team but I really have zero insight into any of it. From a naive perspective, 'read' should mean 'read' full stop.

@mattkime I'm trying to find it in the older version docs but haven't found it yet. But I know those 2 privs have been required when creating index patterns in Kibana for a really long time. I think even before we combined the security plugin (Shield) into x-pack.