Elasticsearch Document- and Field-Level Security | Search Guard
0 likes435 views
The document outlines the features and configurations of Search Guard, focusing on document-level and field-level security in Elasticsearch. It details how to set up dynamic queries and filters for documents and fields based on user roles, including support for LDAP authentication. Additionally, it discusses the performance considerations and the ability to anonymize fields within the data.
Elasticsearch Document- and Field-Level Security | Search Guard
- 1. © 2018 floragunn GmbH - All Rights Reserved SEARCH GUARD DOCUMENT AND FIELD-LEVEL SECURITY DOCUMENTS
- 2. © 2018 floragunn GmbH - All Rights Reserved Search Guard – Document and Field-Level Security 01. WHAT IS IT? Document-level security (DLS) Filter out documents from Elasticsearch result sets Based on (dynamic) DLS queries Assignable to roles and indices Field-level security (FLS) Filter out fields from document Support for blacklists and whitelists Assignable to roles and indices
- 3. © 2018 floragunn GmbH - All Rights Reserved Search Guard – Active Directory & LDAP Authentication LDAP AUTHENTICATION BACKEND ldap: http_enabled: true transport_enabled: true order: 0 http_authenticator: type: basic challenge: false authentication_backend: type: ldap config: enable_ssl: true verify_hostnames: true hosts: - ldap.example.com:636 bind_dn: cn=admin,dc=example,dc=com password: password userbase: 'ou=people,dc=example,dc=com' # Filter to search for users (currently in the whole subtree beneath userbase) # {0} is substituted with the username usersearch: '(sAMAccountName={0})'
- 4. © 2018 floragunn GmbH - All Rights Reserved Search Guard – Document and Field-Level Security 01. WHAT IS IT? Document-level security (DLS) Filter out documents from Elasticsearch result sets Based on (dynamic) DLS queries Assignable to roles and indices Field-level security (FLS) Filter out fields from document Support for blacklists and whitelists Assignable to roles and indices
- 5. © 2018 floragunn GmbH - All Rights Reserved Search Guard – Document and Field-Level Security 02. DLS QUERIES Defined as standard Elasticsearch queries All Elasticsearch query features can be used Query can be as complex as necessary Run “in addition” to original query More precisely: Hides documents on Lucene level Multiple roles and DLS queries A user can be member of multiple roles Thus, multiple DLS queries for the same index can apply Queries are combined by OR
- 6. © 2018 floragunn GmbH - All Rights Reserved Search Guard – Document and Field-Level Security 03.EXAMPLE Filters out all records from the “humanresources” index where the “Designation” field matches “CEO” sg_human_resources: cluster: - CLUSTER_COMPOSITE_OPS indices: 'humanresources': '*': - CRUD _dls_: '{ "bool": { "must_not": { "match": { "Designation": "CEO" }}}}' …
- 7. © 2018 floragunn GmbH - All Rights Reserved Search Guard – Document and Field-Level Security 04. DYNAMIC DLS QUERIES DLS queries support variable substitution username user attributes User attributes LDAP attributes JWT claims Internal user attributes Example _dls_: '{ "bool": { "must": { "match": { "owner": ${user.name} }}}}’
- 8. © 2018 floragunn GmbH - All Rights Reserved Search Guard – Document and Field-Level Security 05. DYNAMIC DLS QUERIES Example: LDAP user record DLS query _dls_: '{ "bool": { "must": { "match": { "department": ${attr.ldap.department} }}}}’ Translates to _dls_: '{ "bool": { "must": { "match": { “department”:"HR"} }}}}’ Very powerful role definitions possible dn: CN=hr_employee,CN=Users,DC=test,DC=local cn: hr_employee … department: HR
- 9. © 2018 floragunn GmbH - All Rights Reserved Search Guard – Document and Field-Level Security 06. FIELD LEVEL SECURITY Example: LDAP user record FLS filters out fields from documents in result set Defined per role and per index Fields can be included or excluded Wildcard and regular expression support
- 10. © 2018 floragunn GmbH - All Rights Reserved Search Guard – Document and Field-Level Security 07.INCLUDING FIELDS sg_human_resources_trainee: cluster: - CLUSTER_COMPOSITE_OPS_RO indices: 'humanresources': '*': - CRUD _dls_: '{ "bool": { "must_not": { "match": { "Designation": "CEO" }}}}' _fls_: - 'Designation' - 'FirstName' - 'LastName' - 'Salary'
- 11. © 2018 floragunn GmbH - All Rights Reserved Search Guard – Document and Field-Level Security 08.EXCLUDING FIELDS, USING WILDCARDS sg_human_resources_trainee: cluster: - CLUSTER_COMPOSITE_OPS_RO indices: 'humanresources': '*': - CRUD _dls_: '{ "bool": { "must_not": { "match": { "Designation": "CEO" }}}}' _fls_: - '~Designation' - '~*Name' - '~Salary'
- 12. © 2018 floragunn GmbH - All Rights Reserved Search Guard – Document and Field-Level Security 09. FLS - MULTIPLE ROLES Fields can be either included or excluded Mixing leads to unpredictable results If user is in multiple roles, make sure to use either include or exclude Fields in multiple roles are combined by AND
- 13. © 2018 floragunn GmbH - All Rights Reserved Search Guard – Document and Field-Level Security 10. FLS - PERFORMANCE CONSIDERATIONS For best performance avoid using wildcards if no wildcards are used, an optimised version of FLS filter can be applied Keep the field list short by choosing include OR exclude
- 14. © 2018 floragunn GmbH - All Rights Reserved Search Guard – Document and Field-Level Security 11. FLS - ANONYMIZIMG FIELDS Fields can be anonymized on-the-fly Field value is replaced by a salted hash Applied at runtime, not ingest time Can be applied to existing indices and data No reindexing necessary Support for String-based fields Wildcard and regular expression support
- 15. © 2018 floragunn GmbH - All Rights Reserved Search Guard – Document and Field-Level Security 12.ANONYMIZING FIELDS sg_human_resources_trainee: cluster: - CLUSTER_COMPOSITE_OPS_RO indices: 'humanresources': '*': - CRUD _dls_: '{ "bool": { "must_not": { "match": { "Designation": "CEO" }}}}' _fls_: - 'Designation' - 'Salary' - 'FirstName' - 'LastName' - 'Address' _masked_fields_: - '*Name' - 'Address'
- 16. © 2018 floragunn GmbH - All Rights Reserved Search Guard – Document and Field-Level Security 13. RESOURCES Search Guard website https://search-guard.com/ Documentation https://docs.search-guard.com Community Forum https://groups.google.com/d/forum/search-guard GitHub https://github.com/floragunncom
- 17. © 2018 floragunn GmbH - All Rights Reserved WE LOOK FORWARD TO YOUR MESSAGE CONTACT US: info@search-guard.com
- 18. © 2018 floragunn GmbH - All Rights Reserved floragunn GmbH Tempelhofer Ufer 16 D-10963 Berlin, Germany E-Mail: info@search-guard.com Web: search-guard.com Managing Directors: Claudia Kressin, Jochen Kressin Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 147010 B E-Mail: info@floragunn.com Search Guard is a trademark of floragunn GmbH, registered in the U.S. and in other countries. Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries. floragunn GmbH is not affiliated with Elasticsearch BV. Search Guard is an independent implementation of a security access layer for Elasticsearch. It is completely independent from Elasticsearch own products.