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
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.
- 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.