Deprecation warning re. granting alias permissions to a role

Elastic Stack Elasticsearch
1

Hi there. I've noticed a bunch of messages in my deprecation logs that go like this:

Role [some-dept] contains index privileges covering the [some-dept-alias] alias but which do not cover some of the indices that it points to [logstash_sysadmins-2021.08.14-000058]. Granting privileges over an alias and hence granting privileges over all the indices that the alias points to is deprecated and will be removed in a future version of Elasticsearch. Instead define permissions exclusively on index names or index name patterns.

The issue I see here is that I'm using filtered aliases to allow users of some-dept to read the logstash_sysadmin* indices, but restricted to only the data from their own systems, while allowing the sysadmin role to read the entire index. I don't see any other way to do this, and modifying the role to include the index as the deprecation warning recommends will allow this group to read the entire index, including events from other departments.

Is there going to be an alternative method to doing this in the future, or are we facing an issue of important functionality being removed? For some departments the event rate is low enough that it doesn't justify creating a separate tiny index for them, which seems to be where we're heading if we want to keep doing this.

2

Using a filtered alias for this behaviour is not secure. See Security limitations | Elasticsearch Guide [8.11] | Elastic

The only support mechanism to provide access to a subset of documents in an index is Document Level Security.

Consider an index like this:

PUT /index-1/
{
    "mappings": {
      "properties": {
        "app": {  "type": "keyword" },
        "value": { "type": "long" }
      }
    },
   "aliases": {
      "app-1": {
        "filter": { "term": { "app": "one" } }
      },
      "app-2": {
        "filter": { "term": { "app": "two" } }
      }
    }
}

A search on index-1 gives:

GET /index-1/_search

===
{
    // ...
    "hits": [
      {
        "_index": "index-1",
        "_type": "_doc",
        "_id": "1",
        "_score": 1.0,
        "_source": { "app": "one", "value": 1 }
      },
      {
        "_index": "index-1",
        "_type": "_doc",
        "_id": "2",
        "_score": 1.0,
        "_source": {  "app": "two", "value": 2 }
      }
    ]
  // ...
}

And a search on app-1 gives what you would expect:

GET /app-1/_search

===
{
    // ...
    "hits": [
      {
        "_index": "index-1",
        "_type": "_doc",
        "_id": "1",
        "_score": 1.0,
        "_source": { "app": "one", "value": 1 }
      }
    ]
    // ...
}

But it's possible to get non-matching documents via that alias:

GET /app-1/_doc/2

===
{
  "_index": "index-1",
  "_type": "_doc",
  "_id": "2",
  "_version": 1,
  "_seq_no": 1,
  "_primary_term": 1,
  "found": true,
  "_source": { "app": "two", "value": 2 }
}
2 Likes
3

Thanks for the reply Tim.

I get that it's not exactly secure, but from my point of view it's a quick and easy way to segregate some users in Kibana, and TBH the data our users are accessing carries no real risk if it's exposed to a different user via a custom query. They're essentially accessing the same data, and it's just filtered into groups of machines that they are responsible for, and this works great for our purposes.

My problem is that as the ability to set permissions on an alias seems to be going away, the only solution is either a mess of individual indices (sometimes very small indices for very small teams), or the purchase of a Platinum license just to get DLS, to reproduce what we essentially already have, albeit in a more secure way.

Is there any likelihood that alias permissions could stay, but perhaps with a warning to the user at the time they set/modify/view these permissions instead? (e.g., "What you're doing is not recommended or secure - are you sure you would still like to do this?")

Cheers.

1 Like
4

It's very unlikely. We're working to remove the security-on-aliases feature because it causes real technical problems. This isn't just a case of "it's not recommended", it's "this doesn't work and the existence of this feature makes it difficult to provide other useful features".

As an example, PIT does not work with Alias security.
We considered supporting alias security in PIT, but the tradeoffs we would have to make to do that would have caused complications (e.g. a high memory and CPU cost) for all Elasticsearch users, in order to provide a feature that has a variety of other problems.

In order to move Elasticsearch forwards we need to stop treating an aliases as having different security properties than the underlying index. It's not about filtered aliases, per se, it's just that alias based security isn't a good feature.

5

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.