Document level Security

Elastic Stack Elasticsearch
1

Hi Everyone,
Active Directory Authentication is enabled in my ELK stack.
Now i want a AD user for eg user= 'John' to see only data for country='US'
how can i achieve that please help.

Regards,
Tausif Khan.

2

You want to read: https://www.elastic.co/guide/en/x-pack/current/field-and-document-access-control.html

3

I read it but couldn't understand much can i do the same in kibana GUI, under management section ?

4

I couldn't find in that document related to the query which i asked , could you please help with the query rather then the link.

5

I don't have a laptop nearby but IIRC the Kibana interface there is this option in user management UI.

May be someone else can give more details

6

the role query should be very simple:

{"term" : { "country" : "US" }}

And we have two options here:

  • you have the correct role mapping in the AD realm section:

      files:
    role_mapping: "/etc/elasticsearch/x-pack/role_mapping.yml"

role_mapping.yml:

role_name:
  - "CN=johns_group,dc=corp,dc=org"

OR

  • put this parameter unmapped_groups_as_roles: true to your AD config section and make sure the role name is one of the group the user "John" belongs to
1 Like
7

While unmapped_groups_as_roles can be useful in a small number of cases, it really should be avoided unless you absolutely need to use it.
The role_mapping.yml approach is the preferred solution in this case.

8

Any particular reason, why it should be avoided? From my point of view, it's a very cool feature - all groups can be managed in AD directly, and you don't need to manage one additional mapping file (role_mapping.yml). And nested groups are supported!
The only concern I could imaging - a security issue: if you create the "superuser" group and include your user into it, you'll get full access to the cluster.
Any other pitfalls?..

9

Could you please assist on your way of approach.

10

There are security, performance and maintainability impacts that are sometimes a necessary price to pay, but we find that a lot of people turn on unmapped_groups_as_roles as a trivial convenience - a way to avoid editing a file once or twice - and don't appreciate or consider the impacts on their cluster.

Some of the consequences to consider when using unmapped_groups_as_roles:

  • Your are delegating full security access to your cluster to the administrators of the directory. If an AD admin adds a user to a superuser group in AD, then they get the superuser role in Elasticsearch, and you can't prevent it.
  • You have to plan you group/role naming well, or you will run into unintended overlaps or misaligned roles. Generally speaking, an AD admin will assume that creating a brand new group in the directory and assigning it to a user is a totally safe operation, and will not affect dependent applications. But if unmapped_groups_as_roles is enabled, then any new group that matches with an Elasticsearch role will unintentionally change the user's Elasticsearch permissions.
  • If a user has a large number of AD groups then Elasticsearch needs to try and load a role for each one of them, even though that role probably doesn't exist. This overhead is larger than you might expect it to be.

unmapped_groups_as_roles has uses, but it's not completely safe in all cases, so if you're just using it to avoid editing role_mapping.yml then that's often the wrong trade-off.

1 Like
11

Thank you very much for the comprehensive reply, I really appreciate that.

  1. yes, the security issue is a very important one, I asked already here, on some other topic, that would be great, if you could extend the AD configuration by adding a black (or white-) -list feature, so, only the AD groups, let's say, containing ELK would be mapped.
  2. the group naming should not be an issue, as, from my experience, all modern organizations use naming standards on their infrastructure already.
  3. large number of AD groups - yes, that's true, an account has a lot of AD groups usually. But I thought, since the groups get cached, it shouldn't impact on performance much. Ok, we'll check the time spent on mapping from the authc trace-logs.

Thanks a lot!

12

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