How to apply document level security?

Hi,

SG, ES Version: 6.2.3

Requirement: The Salary field for the Role “CEO” must not appear when I log in as user l1_user.

  • I have the following data in an index called company_details in my ES instance:

Role
Task
Salary
Count
CEO

RULE THE COMPANY

5,000

1
CIO

RULE THE TECHNOLOGY

4,000

1
CFO

RULE THE FINANCE

3,000

1
ROLE G

TASK G

1,700

1
ROLE F

TASK F

1,500

1
ROLE E

TASK E

1,500

1
ROLE C

TASK C

1,500

1
ROLE B

TASK B

1,500

1
ROLE D

TASK D

1,000

1
ROLE A

TASK A

1,000

1

  • I have created a new Search Guard Role called L1. I have given UNLIMITED cluster permissions to it.

  • I have given following index permissions to it:

Index: company_details

Document Type: _doc

Permissions Action Groups: UNLIMITED

  • Under DLS/FLS Document Level Security Query, I have put the following query:

{

“bool”: {

“must_not”: {

“match”: {

“Role”: “CEO”

}

}

}

}

Under Include or exclude fields, I have set it to “Exclude fields” Salary.

  • No tenants

  • In the Internal User Database, my user is l1_user with no Backend Roles assigned to it.

  • In Role Mappings: Search Guard Role: L1

Users: l1_user

Backend Roles: kibanauser

Hosts: None

Now, ideally when I login as l1_user and go into my discover tab, I should not be able to see the document with the role “CEO”, correct? But nothing happens, I can see all the documents. What am I doing wrong?

Thanks,

Pratiksha

Just to make sure: If you use the configuration you described, the CEO document will be filtered from the result set, and the Salary field will also be filtered for all documents. Is this what you want to achieve? Regarding your question:

Let’s first check the role definition. In the GUI, please select the role L1. You will see a button “Show JSON” in the upper right corner. Click on it and please post the contents here. Do the same also for the L1 roles mapping.

Next, can you visit this endpoint:

https://:/_searchguard/authinfo

Log in with your l1_user and post the output here.

···

On Tuesday, May 22, 2018 at 7:50:27 PM UTC+2, Pratiksha Tewary wrote:

Hi,

SG, ES Version: 6.2.3

Requirement: The Salary field for the Role “CEO” must not appear when I log in as user l1_user.

  • I have the following data in an index called company_details in my ES instance:

Role
Task
Salary
Count
CEO

RULE THE COMPANY

5,000

1
CIO

RULE THE TECHNOLOGY

4,000

1
CFO

RULE THE FINANCE

3,000

1
ROLE G

TASK G

1,700

1
ROLE F

TASK F

1,500

1
ROLE E

TASK E

1,500

1
ROLE C

TASK C

1,500

1
ROLE B

TASK B

1,500

1
ROLE D

TASK D

1,000

1
ROLE A

TASK A

1,000

1

  • I have created a new Search Guard Role called L1. I have given UNLIMITED cluster permissions to it.
  • I have given following index permissions to it:

Index: company_details

Document Type: _doc

Permissions Action Groups: UNLIMITED

  • Under DLS/FLS Document Level Security Query, I have put the following query:

{

“bool”: {

“must_not”: {

“match”: {

“Role”: “CEO”

}

}

}

}

Under Include or exclude fields, I have set it to “Exclude fields” Salary.

  • No tenants
  • In the Internal User Database, my user is l1_user with no Backend Roles assigned to it.
  • In Role Mappings: Search Guard Role: L1

Users: l1_user

Backend Roles: kibanauser

Hosts: None

Now, ideally when I login as l1_user and go into my discover tab, I should not be able to see the document with the role “CEO”, correct? But nothing happens, I can see all the documents. What am I doing wrong?

Thanks,

Pratiksha

Hi Jochen,

Thank you for responding.

I actually just want the Document containing the Role “CEO” to not appear for this user. So, I believe this can be achieved by just posting the DSL query that I had mentioned initially (without having to specify any inclusions or exclusions of fields), correct?

Following is the info you requested:

JSON for Role L1:

{

“cluster”: [

“UNLIMITED”

],

“indices”: {

“*”: {

“*”: [

“UNLIMITED”

],

dls”: “{“bool”:{“must_not”:{“match”:{“Role”:“CEO”}}}}”

}

},

“tenants”: {}

}

JSON for L1 Role Mapping:

{

“backendroles”: [

“kibanauser”

],

“hosts”: ,

“users”: [

“l1_user”

]

}

Output at endpoint by logging in as l1_user:

{"user":"User [name=l1_user, roles=[], requestedTenant=null]","user_name":"l1_user","user_requested_tenant":null,"remote_address":"[::1]:60290","backend_roles":[],"custom_attribute_names":[],"sg_roles":["L1","sg_own_index"],"sg_tenants":{"l1_user":true},"principal":null,"peer_certificates":"0"}
···

On Wednesday, May 23, 2018 at 4:38:37 AM UTC-4, Jochen Kressin wrote:

Just to make sure: If you use the configuration you described, the CEO document will be filtered from the result set, and the Salary field will also be filtered for all documents. Is this what you want to achieve? Regarding your question:

Let’s first check the role definition. In the GUI, please select the role L1. You will see a button “Show JSON” in the upper right corner. Click on it and please post the contents here. Do the same also for the L1 roles mapping.

Next, can you visit this endpoint:

https://:/_searchguard/authinfo

Log in with your l1_user and post the output here.

On Tuesday, May 22, 2018 at 7:50:27 PM UTC+2, Pratiksha Tewary wrote:

Hi,

SG, ES Version: 6.2.3

Requirement: The Salary field for the Role “CEO” must not appear when I log in as user l1_user.

  • I have the following data in an index called company_details in my ES instance:

Role
Task
Salary
Count
CEO

RULE THE COMPANY

5,000

1
CIO

RULE THE TECHNOLOGY

4,000

1
CFO

RULE THE FINANCE

3,000

1
ROLE G

TASK G

1,700

1
ROLE F

TASK F

1,500

1
ROLE E

TASK E

1,500

1
ROLE C

TASK C

1,500

1
ROLE B

TASK B

1,500

1
ROLE D

TASK D

1,000

1
ROLE A

TASK A

1,000

1

  • I have created a new Search Guard Role called L1. I have given UNLIMITED cluster permissions to it.
  • I have given following index permissions to it:

Index: company_details

Document Type: _doc

Permissions Action Groups: UNLIMITED

  • Under DLS/FLS Document Level Security Query, I have put the following query:

{

“bool”: {

“must_not”: {

“match”: {

“Role”: “CEO”

}

}

}

}

Under Include or exclude fields, I have set it to “Exclude fields” Salary.

  • No tenants
  • In the Internal User Database, my user is l1_user with no Backend Roles assigned to it.
  • In Role Mappings: Search Guard Role: L1

Users: l1_user

Backend Roles: kibanauser

Hosts: None

Now, ideally when I login as l1_user and go into my discover tab, I should not be able to see the document with the role “CEO”, correct? But nothing happens, I can see all the documents. What am I doing wrong?

Thanks,

Pratiksha

can you please post your elasticsearch.yml and the output of the license endpoint

http(s)://server:port/_searchguard/license

···

Am 23.05.2018 um 16:22 schrieb Pratiksha Tewary <pratikshatewary@gmail.com>:

Hi Jochen,

Thank you for responding.

I actually just want the Document containing the Role "CEO" to not appear for this user. So, I believe this can be achieved by just posting the DSL query that I had mentioned initially (without having to specify any inclusions or exclusions of fields), correct?

Following is the info you requested:

JSON for Role L1:

{
  "cluster": [
    "UNLIMITED"
  ],
  "indices": {
    "*": {
      "*": [
        "UNLIMITED"
      ],
      "_dls_": "{\"bool\":{\"must_not\":{\"match\":{\"Role\":\"CEO\"}}}}"
    }
  },
  "tenants": {}
}

JSON for L1 Role Mapping:

{
  "backendroles": [
    "kibanauser"
  ],
  "hosts": ,
  "users": [
    "l1_user"
  ]
}

Output at endpoint by logging in as l1_user:

{"user":"User [name=l1_user, roles=, requestedTenant=null]","user_name":"l1_user","user_requested_tenant":null,"remote_address":"[::1]:60290","backend_roles":,"custom_attribute_names":,"sg_roles":["L1","sg_own_index"],"sg_tenants":{"l1_user":true},"principal":null,"peer_certificates":"0"}

On Wednesday, May 23, 2018 at 4:38:37 AM UTC-4, Jochen Kressin wrote:
Just to make sure: If you use the configuration you described, the CEO document will be filtered from the result set, and the Salary field will also be filtered for all documents. Is this what you want to achieve? Regarding your question:

Let's first check the role definition. In the GUI, please select the role L1. You will see a button "Show JSON" in the upper right corner. Click on it and please post the contents here. Do the same also for the L1 roles mapping.

Next, can you visit this endpoint:

https://<eshost>:<port>/_searchguard/authinfo

Log in with your l1_user and post the output here.

On Tuesday, May 22, 2018 at 7:50:27 PM UTC+2, Pratiksha Tewary wrote:
Hi,

SG, ES Version: 6.2.3
Requirement: The Salary field for the Role "CEO" must not appear when I log in as user l1_user.

- I have the following data in an index called company_details in my ES instance:

Role Task Salary Count
CEO
RULE THE COMPANY
5,000
1
CIO
RULE THE TECHNOLOGY
4,000
1
CFO
RULE THE FINANCE
3,000
1
ROLE G
TASK G
1,700
1
ROLE F
TASK F
1,500
1
ROLE E
TASK E
1,500
1
ROLE C
TASK C
1,500
1
ROLE B
TASK B
1,500
1
ROLE D
TASK D
1,000
1
ROLE A
TASK A
1,000
1

- I have created a new Search Guard Role called L1. I have given UNLIMITED cluster permissions to it.

- I have given following index permissions to it:

Index: company_details
Document Type: _doc
Permissions Action Groups: UNLIMITED

- Under DLS/FLS Document Level Security Query, I have put the following query:
{
  "bool": {
    "must_not": {
      "match": {
        "Role": "CEO"
      }
    }
  }
}

Under Include or exclude fields, I have set it to "Exclude fields" Salary.

- No tenants

- In the Internal User Database, my user is l1_user with no Backend Roles assigned to it.

- In Role Mappings: Search Guard Role: L1
                                Users: l1_user
                                Backend Roles: kibanauser
                                Hosts: None

Now, ideally when I login as l1_user and go into my discover tab, I should not be able to see the document with the role "CEO", correct? But nothing happens, I can see all the documents. What am I doing wrong?

Thanks,
Pratiksha

--
You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com.
To post to this group, send email to search-guard@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/47778fd0-c2d8-45ba-8447-233804b79abd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

elasticsearch.yml file:

searchguard.ssl.transport.pemcert_filepath: esnode.pem

searchguard.ssl.transport.pemkey_filepath: esnode-key.pem

searchguard.ssl.transport.pemtrustedcas_filepath: root-ca.pem

searchguard.ssl.transport.enforce_hostname_verification: false

searchguard.ssl.http.enabled: true

searchguard.ssl.http.pemcert_filepath: esnode.pem

searchguard.ssl.http.pemkey_filepath: esnode-key.pem

searchguard.ssl.http.pemtrustedcas_filepath: root-ca.pem

searchguard.allow_unsafe_democertificates: true

searchguard.allow_default_init_sgindex: true

searchguard.authcz.admin_dn:

  • CN=kirk,OU=client,O=client,L=test, C=de

searchguard.audit.type: internal_elasticsearch

searchguard.enable_snapshot_restore_privilege: true

searchguard.check_snapshot_restore_write_privileges: true

searchguard.restapi.roles_enabled: [“sg_all_access”]

cluster.name: searchguard_demo

discovery.zen.minimum_master_nodes: 1

node.max_local_storage_nodes: 3

Output of license endpoint:

{"_nodes":{"total":1,"successful":1,"failed":0},"cluster_name":"searchguard_demo","sg_license":{"uid":"00000000-0000-0000-0000-000000000000","type":"TRIAL","issue_date":"2018-05-02","expiry_date":"2018-07-02","issued_to":"The world","issuer":"floragunn GmbH","start_date":"2018-05-02","major_version":6,"cluster_name":"*","msgs":[],"expiry_in_days":37,"is_expired":false,"is_valid":true,"action":"","prod_usage":"Yes, one cluster with all commercial features and unlimited nodes per cluster.","license_required":true,"allowed_node_count_per_cluster":"unlimited"},"modules":{"AUDITLOG":{"default_implementation":"com.floragunn.searchguard.auditlog.impl.AuditLogImpl","gitsha1":"d29db0393dfbbd2038a88b1a6e44acfb3c4eb8e7","buildTime":"2018-03-26T15:58:18Z","is_enterprise":"true","actual_implementation":"com.floragunn.searchguard.auditlog.impl.AuditLogImpl","description":"Audit Logging","type":"AUDITLOG","version":"6.2.3-31.0"},"MULTITENANCY":{"default_implementation":"com.floragunn.searchguard.configuration.PrivilegesInterceptorImpl","gitsha1":"d29db0393dfbbd2038a88b1a6e44acfb3c4eb8e7","buildTime":"2018-03-26T15:58:18Z","is_enterprise":"true","actual_implementation":"com.floragunn.searchguard.configuration.PrivilegesInterceptorImpl","description":"Kibana Multitenancy","type":"MULTITENANCY","version":"6.2.3-31.0"},"DLSFLS":{"default_implementation":"com.floragunn.searchguard.configuration.SearchGuardFlsDlsIndexSearcherWrapper","gitsha1":"d29db0393dfbbd2038a88b1a6e44acfb3c4eb8e7","buildTime":"2018-03-26T15:58:18Z","is_enterprise":"true","actual_implementation":"com.floragunn.searchguard.configuration.SearchGuardFlsDlsIndexSearcherWrapper","description":"Document- and Field-Level Security","type":"DLSFLS","version":"6.2.3-31.0"},"HTTP_BASIC_AUTHENTICATOR":{"default_implementation":"com.floragunn.searchguard.http.HTTPBasicAuthenticator","gitsha1":"4d721763b090d2a26c76487ebb0294497c383010","buildTime":"2018-03-27T09:08:09Z","is_enterprise":"false","actual_implementation":"com.floragunn.searchguard.http.HTTPBasicAuthenticator","description":"HTTP Basic Authenticator","type":"HTTP_BASIC_AUTHENTICATOR","version":"6.2.3-22.0"},"INTERNAL_USERS_AUTHENTICATION_BACKEND":{"default_implementation":"com.floragunn.searchguard.auth.internal.InternalAuthenticationBackend","gitsha1":"4d721763b090d2a26c76487ebb0294497c383010","buildTime":"2018-03-27T09:08:09Z","is_enterprise":"false","actual_implementation":"com.floragunn.searchguard.auth.internal.InternalAuthenticationBackend","description":"Internal users authorization backend","type":"INTERNAL_USERS_AUTHENTICATION_BACKEND","version":"6.2.3-22.0"},"REST_MANAGEMENT_API":{"default_implementation":"com.floragunn.searchguard.dlic.rest.api.SearchGuardRestApiActions","gitsha1":"d29db0393dfbbd2038a88b1a6e44acfb3c4eb8e7","buildTime":"2018-03-26T15:58:18Z","is_enterprise":"true","actual_implementation":"com.floragunn.searchguard.dlic.rest.api.SearchGuardRestApiActions","description":"REST Management API","type":"REST_MANAGEMENT_API","version":"6.2.3-31.0"}},"compatibility":{"modules_mismatch":false}}


···

On Thursday, May 24, 2018 at 4:09:31 PM UTC-4, Search Guard wrote:

can you please post your elasticsearch.yml and the output of the license endpoint

http(s)://server:port/_searchguard/license

Am 23.05.2018 um 16:22 schrieb Pratiksha Tewary pratiks...@gmail.com:

Hi Jochen,

Thank you for responding.

I actually just want the Document containing the Role “CEO” to not appear for this user. So, I believe this can be achieved by just posting the DSL query that I had mentioned initially (without having to specify any inclusions or exclusions of fields), correct?

Following is the info you requested:

JSON for Role L1:

{

“cluster”: [

"UNLIMITED"

],

“indices”: {

"*": {
  "*": [
    "UNLIMITED"
  ],
  "_dls_": "{\"bool\":{\"must_not\":{\"match\":{\"Role\":\"CEO\"}}}}"
}

},

“tenants”: {}

}

JSON for L1 Role Mapping:

{

“backendroles”: [

"kibanauser"

],

“hosts”: ,

“users”: [

"l1_user"

]

}

Output at endpoint by logging in as l1_user:

{“user”:“User [name=l1_user, roles=, requestedTenant=null]”,“user_name”:“l1_user”,“user_requested_tenant”:null,“remote_address”:"[::1]:60290",“backend_roles”:,“custom_attribute_names”:,“sg_roles”:[“L1”,“sg_own_index”],“sg_tenants”:{“l1_user”:true},“principal”:null,“peer_certificates”:“0”}

On Wednesday, May 23, 2018 at 4:38:37 AM UTC-4, Jochen Kressin wrote:

Just to make sure: If you use the configuration you described, the CEO document will be filtered from the result set, and the Salary field will also be filtered for all documents. Is this what you want to achieve? Regarding your question:

Let’s first check the role definition. In the GUI, please select the role L1. You will see a button “Show JSON” in the upper right corner. Click on it and please post the contents here. Do the same also for the L1 roles mapping.

Next, can you visit this endpoint:

https://:/_searchguard/authinfo

Log in with your l1_user and post the output here.

On Tuesday, May 22, 2018 at 7:50:27 PM UTC+2, Pratiksha Tewary wrote:

Hi,

SG, ES Version: 6.2.3

Requirement: The Salary field for the Role “CEO” must not appear when I log in as user l1_user.

  • I have the following data in an index called company_details in my ES instance:

Role Task Salary Count
CEO

RULE THE COMPANY

5,000

1

CIO

RULE THE TECHNOLOGY

4,000

1

CFO

RULE THE FINANCE

3,000

1

ROLE G

TASK G

1,700

1

ROLE F

TASK F

1,500

1

ROLE E

TASK E

1,500

1

ROLE C

TASK C

1,500

1

ROLE B

TASK B

1,500

1

ROLE D

TASK D

1,000

1

ROLE A

TASK A

1,000

1

  • I have created a new Search Guard Role called L1. I have given UNLIMITED cluster permissions to it.

  • I have given following index permissions to it:

Index: company_details

Document Type: _doc

Permissions Action Groups: UNLIMITED

  • Under DLS/FLS Document Level Security Query, I have put the following query:

{

“bool”: {

"must_not": {
  "match": {
    "Role": "CEO"
  }
}

}

}

Under Include or exclude fields, I have set it to “Exclude fields” Salary.

  • No tenants
  • In the Internal User Database, my user is l1_user with no Backend Roles assigned to it.
  • In Role Mappings: Search Guard Role: L1
                            Users: l1_user
                            Backend Roles: kibanauser
                            Hosts: None

Now, ideally when I login as l1_user and go into my discover tab, I should not be able to see the document with the role “CEO”, correct? But nothing happens, I can see all the documents. What am I doing wrong?

Thanks,

Pratiksha


You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.

To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.

To post to this group, send email to search...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/47778fd0-c2d8-45ba-8447-233804b79abd%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.