Granular document level security

Search Guard
1

Hi,

We have multiple users in each tenant. Each user belongs one or more applications. Each application has unique application ID which is available in logs. We want to present the users the application data they belong to.

For example:

User 1 is part of application A in Developer tenant. User 1 should be able to see only Application A data.

User 2 is part of application B in Developer tenant. User 2 should be able to see only Application B data.

User 3 is part of application A and B in Developer tenant. User 3 should be able to see data for both Application A and Application B.

Is it possible with SearchGuard DLSFLS. It would be great if you can provide example.

Thanks,

Rakesh

2

Hi Rakesh,

I’m not 100% sure if I understand your wording correctly, what exactly do you mean by “application” and “tenant”? But let me give it a try:

I assume that you have one index which contains documents from Application A, Application B etc. Some users should get access to documents from Applcation A, others to documents from Application B, and others should get access to both, correct? I’m also assuming that you do not use the document type feature of ES to distinguish between those data, but instead you have some field in your documents which defines to which application it belongs.

For this scenario, you need to set up different roles and apply a DLS query which grants access to only certain documents. So, let’s say your index is called “applicationdata”, and you have a field called “application” in each document, which can contain either applicationA or applicationB, you would set up the roles like this:

roleA:
…
indices:
‘applicationdata’:
‘*’:
- CRUD
dls: ‘{ “bool”: { “must”: { “match”: { “application”: “applicationA” }}}}’

``

roleB:
…
indices:
‘applicationdata’:
‘*’:
- CRUD
dls: ‘{ “bool”: { “must”: { “match”: { “application”: “applicationB” }}}}’

``

Users in roleA only see documents where the “application” field equals applicationA. Users in roleB only see documents where the “application” field equals applicationB. Users in both roleA and roleB see both.

There’s also a blog post about DLS/FLS with some examples:

https://floragunn.com/document-field-level-security-search-guard/

And of course also read the DLS/FLS docs:

https://github.com/floragunncom/search-guard-docs/blob/master/dlsfls.md

···

On Thursday, May 25, 2017 at 11:53:57 PM UTC+2, Rakesh wrote:

Hi,

We have multiple users in each tenant. Each user belongs one or more applications. Each application has unique application ID which is available in logs. We want to present the users the application data they belong to.

For example:

User 1 is part of application A in Developer tenant. User 1 should be able to see only Application A data.

User 2 is part of application B in Developer tenant. User 2 should be able to see only Application B data.

User 3 is part of application A and B in Developer tenant. User 3 should be able to see data for both Application A and Application B.

Is it possible with SearchGuard DLSFLS. It would be great if you can provide example.

Thanks,

Rakesh

3

Hi JK,

Thanks! I think creating multiple roles would work. I have few questions about it such as:

  1. Can we have multiple applications in on dls because we have 100’s of applications data in one index. e.g dls: ‘{ “bool”: { “must”: { “match”: { “application”: “applicationA”, “applicationB”, “applicationC” }}}}’

  2. Can we update dls using SearchGuard Rest API?

  3. Users with roleB access would see only applicationB data in Visualizations?

Best Regards,

Rakesh

4

Hi Rakesh,

  1. The DLS query is just a regular Elasticsearch query. It can be as simple or as complex as you need it to be, and you can use all features of the Elastic query syntax / features. In your case you probably want to use a bool query and combine the fields with “should”:

  1. No, at the moment this is not supported. It would be a nice addition though, so I’m putting it in the back log.

  2. Yes. If you have a dashboard with 2 visualizations, one based on applicanA data, one based on applicationB data, and the user only has access to applicationB documents, then the other visualization will simply be empty.

If you want to have a seperation by users/roles also on a dashboard and visualization level, you should check out our Kibana multi tenancy module, which provides exactly that:

https://github.com/floragunncom/search-guard-docs/blob/master/multitenancy.md

···

On Friday, May 26, 2017 at 7:13:55 PM UTC+2, Rakesh wrote:

Hi JK,

Thanks! I think creating multiple roles would work. I have few questions about it such as:

  1. Can we have multiple applications in on dls because we have 100’s of applications data in one index. e.g dls: ‘{ “bool”: { “must”: { “match”: { “application”: “applicationA”, “applicationB”, “applicationC” }}}}’
  1. Can we update dls using SearchGuard Rest API?
  1. Users with roleB access would see only applicationB data in Visualizations?

Best Regards,

Rakesh

5

Hi JK,

Got it! Thanks for the clarification.

  1. No, at the moment this is not supported. It would be a nice addition though, so I’m putting it in the back log.

I could see REST api to create role at https://github.com/floragunncom/search-guard-docs/blob/master/managementapi.md

so I guess deleting existing role and creating it with updated DLS may work.

Thanks again!

Rakesh

6

Hi Rakesh,

sorry, my mistake. You’re absolutely right, the REST API supports role management, which of course includes updating the document level security settings!

Thanks,

Jochen

···

On Friday, May 26, 2017 at 10:32:06 PM UTC+2, Rakesh wrote:

Hi JK,

Got it! Thanks for the clarification.

  1. No, at the moment this is not supported. It would be a nice addition though, so I’m putting it in the back log.

I could see REST api to create role at https://github.com/floragunncom/search-guard-docs/blob/master/managementapi.md

so I guess deleting existing role and creating it with updated DLS may work.

Thanks again!

Rakesh

7

I am trying to use REST API to get/add roles and getting SSL error as unable to load client cert. cdelkdev.jks is the admin certificate and I have already added following line in elasticsearch.yml.
searchguard.ssl.http.clientauth_mode: OPTIONAL. Any other format of cert is expected?

curl -D- -k https://servername:9200/_searchguard/api/configuration/roles?pretty --cert /etc/elasticsearch/newcertsAllImported/cdelkdev.jks --key /etc/elasticsearch/newcertsAllImported/cdelkdev.jks

curl: (58) Unable to load client cert -8018.

REST API for Elasticsearch works well.

curl -u admin https://servername:9200

Enter host password for user ‘admin’:

{

“name” : “node34D”,

“cluster_name” : “cd_elk_cluster-dev”,

“cluster_uuid” : “rvfvsdfvsdvvvds”,

“version” : {

"number" : "5.2.2",

"build_hash" : "f9d9b74",

"build_date" : "2017-02-24T17:26:45.835Z",

"build_snapshot" : false,

"lucene_version" : "6.4.1"

},

“tagline” : “You Know, for Search”

}

Sorry to ask this question here.

Thanks,

Rakesh

8

Tried with crt and key files and it is asking for sgadmin permissions. ./sgadmin works fine with .jks format of same cert.

curl -u admin -k https://servername:9200/_searchguard/api/configuration/roles?pretty --cert /etc/elasticsearch/cdelkdevcerts/cdmonitoring-dev.phx.aexp.com.CRT --key /etc/elasticsearch/cdelkdevcerts/cdmonitoring-dev.key

Enter host password for user ‘admin’:

SG admin permissions required

Thanks,

Rakesh

···
9

Hi Rakesh,

when you use curl to access the REST API, you don’t need to specify a username/password via the -u switch.

Let me take a small detour to clarify things:

In Search Guard terminology, a user is anyone who accesses Elasticsearch (Kibana, Logstash) directly to perform some common actions like indexing or retrieving documents.

For any Search Guard specific activity that requires heightened privileges, you need a TLS certificate. These heightened privileges especially include making changes to the Search Guard configuration index. This index contains sensitive information, and must not be altered by a regular user. Heightened privileges also apply for nodes in your cluster. Nodes must be able to talk to each other and execute any action, without any restrictions.

That’s why Search Guard requires TLS certificates for identifying trusted nodes in the cluster, and for allowing changes to the Search Guard configuration index.

So, you do not need to specify the -u switch here, since the call to the REST API (which changes the SG config index) is validated by the TLS certificate.

Let me know if you have more questions around this topic!

···

On Tuesday, May 30, 2017 at 9:53:00 PM UTC+2, Rakesh wrote:

Tried with crt and key files and it is asking for sgadmin permissions. ./sgadmin works fine with .jks format of same cert.

curl -u admin -k https://servername:9200/_searchguard/api/configuration/roles?pretty --cert /etc/elasticsearch/cdelkdevcerts/cdmonitoring-dev.phx.aexp.com.CRT --key /etc/elasticsearch/cdelkdevcerts/cdmonitoring-dev.key

Enter host password for user ‘admin’:

SG admin permissions required

Thanks,

Rakesh

10

Hi JK,

Thank you for the information. It is helpful.

When I try without “-u”, it is throwing following error:

HTTP/1.1 401 Unauthorized

access-control-allow-credentials: true

WWW-Authenticate: Basic realm=“Search Guard”

content-type: text/plain; charset=UTF-8

content-length: 12

Can we set up access-control-allow-credentials false.

Thanks,

Rakesh

11

Any comments on “401 Unauthorized”

12

This can have two reasons, a) the provided certificates are not valid or b) the HTTP client auth is not enabled.

If you try to connect via curl, do you see anything in the Elasticsearch logfiles?

Also, can you please check that the HTTP client authentication is enabled in elasticsearch.yml like:

searchguard.ssl.http.clientauth_mode: OPTIONAL

As described in the docs here:

https://github.com/floragunncom/search-guard-docs/blob/master/managementapi.md

···

On Wednesday, May 31, 2017 at 9:15:27 PM UTC+2, Rakesh wrote:

Any comments on “401 Unauthorized”