Authorization per alias problem

Hello there,
I'm using elastic-search, kibana and x-pack version 5.1.2, I'm using the native user-store.
I have two different aliases and templates:

$ cat irldf-campaign_manager_stats_template.json
{
    "aliases": {
        "irldf-campaign_stats": {}
    },
    "mappings": {
        "campaign_stats": {
            "properties": {
...
        }
    },
    "template": "irldf-campaign_manager_stats-*"
}
$ cat irlh3-campaign_manager_stats_template.json
{
    "aliases": {
        "irlh3-campaign_stats": {}
    },
    "mappings": {
        "campaign_stats": {
            "properties": {
...            
        }
    },
    "template": "irlh3-campaign_manager_stats-*"
}
$ !1079
curl -XGET -u elastic 'localhost:9200/_cat/aliases?pretty';
Enter host password for user 'elastic':
irlh3-campaign_stats irlh3-campaign_manager_stats-test - - -
irldf-campaign_stats irldf-campaign_manager_stats-test - - -

Then I've configured two roles associated with both aliases and assigned them to users:

$ curl -XGET 'localhost:9200/_xpack/security/role?pretty'
{
...
  "irlh3" : {
    "cluster" : [ ],
    "indices" : [
      {
        "names" : [
          "irlh3-campaign_stats"
        ],
        "privileges" : [
          "all"
        ]
      },
      {
        "names" : [
          ".kibana*"
        ],
        "privileges" : [
          "manage",
          "read",
          "index"
        ]
      },
      {
        "names" : [
          ".reporting*"
        ],
        "privileges" : [
          "manage",
          "read",
          "index"
        ]
      }
    ],
    "run_as" : [ ],
    "metadata" : { }
  },
  "irldf" : {
    "cluster" : [ ],
    "indices" : [
      {
        "names" : [
          "irldf-campaign_stats"
        ],
        "privileges" : [
          "all"
        ]
      },
      {
        "names" : [
          ".kibana*"
        ],
        "privileges" : [
          "manage",
          "read",
          "index"
        ]
      },
      {
        "names" : [
          ".reporting*"
        ],
        "privileges" : [
          "manage",
          "read",
          "index"
        ]
      }
    ],
    "run_as" : [ ],
    "metadata" : { }
  }
}
$ curl -XGET 'localhost:9200/_xpack/security/user/irldf_user?pretty';
{
  "irldf_user" : {
    "username" : "irldf_user",
    "roles" : [
      "irldf",
      "kibana_user",
      "reporting_user"
    ],
    "full_name" : "IRLDF User",
    "email" : "xrldf@anony.mous",
    "metadata" : { },
    "enabled" : true
  }
}

In kibana I create two visualization, one on each alias, and I put each visualization in separate dashboards. However, if I log into kibana with say the irldf_user I can still see the data from both visualizations in both dashboards. That is, the authorization is not working as I expected? Did I make a mistake settings this up? I'm implementing a separate index per user model.

Looks right to me, are you sure that the data you're seeing is from the other index? How are you checking that?

Hello Spencer,
Thanks for your reply.
I log into kibana as user, irldf_user. Then I can navigate to the dashboard irlh3_System_Dashboard, which I was expecting to be accessible. The irlh3_System_Dashboard contains one visualization irlh3_Offers which was created against the irlh3-campaign_stats alias. The irldf_user should not be able to access the irlh3-campaign_stats data. However, it seems to and returns content, so the irldf_user accesses data he is not supposed to have access to.

One thing that might be unusual here from above is that the mapping type is campaign_stats in both templates. I changed this so it was unique for each template but I got the same result. My elasticsearch.yml security config is:

xpack.security.enabled: true
xpack.security.audit.enabled: true
xpack.security.transport.ssl.enabled: false
xpack.security.http.ssl.enabled: false
xpack.security.authc:
  realms:
    native:
      type: native
      order: 0
    tango-ims-realm:
      type: tango-ims-realm
      order: 1
      maxConnections: 5
      maxConnectionsPerHost: 5
      connectionTimeout: 5000
      socketTimeout: 5000
      imsCacheSizeName: 100
      imsCacheExpiryInMinutes: 5
      serviceUrl: "http://localhost:8225"
  anonymous:
    username: _es_anonymous_user
    roles: superuser, transport_client
    authz_exception: true

Is it mandatory for my alias to be configured with a filter perhaps? I didn't use the filter feature as I'm operating a per tenant/user tenant, rather than including a single index containing a tenantId accessible with alias with configured filter.

are you sure that the data you're seeing is from the other index? How are you checking that?

I guess what I meant to say is how do you know that the data in the irlh3_Offers visualization is actually reading only from the irlh3-campaign_stats data? I just recreated this exact scenario locally and this I see the expected results:

Two users (but I only gave them the irlh3/irldf roles)

irldf role only has access to irldf-campaign_stats, kibana, and reporting:

Same for irlh3 role, but for irlh3-campaign_stats:

irlh3-campaign_stats index pattern:

irlh3_Offers visualization (based on irdh3-campaign_stats index pattern):

irlh3_System_Dashboard from the perspective of irlh3_user (last 24 hours):

irlh3_System_Dashbaord from the perspective of irldf_user (last 24 hours):

Because of this I assume you've mapped something incorrectly (which I did several times while trying to prepare these screenshots). Can you try to take a list of screenshots like this so I can help verify that everything lines up?

Perhaps I could recommend a different approach? If you continue to index the data for irldf and irlh3 into indexes with different prefixes, and then only give them access to indices with that prefix, then you can use a single index pattern for something like *-campaign_manager_stats-* and elasticsearch will take care of resolving which indexes each user has access to. This way there is just an Offers visualization and a System Dashboard dashboard, and they automatically show the data relevant to each user.

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