Elasticsearch

<slideshow style="nobleprog" headingmark="⌘" incmark="…" scaled="true" font="Trebuchet MS" >

title

Elasticsearch

author

Bernard Szlachta 安博 (NobleProg Ltd)

</slideshow>

Copyright Notice

Copyright © 2004-2025 by NobleProg Limited All rights reserved.

This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise.

Elasticsearch Access Control⌘

1. Access Control in ES (least secure)
   1. Shield
   2. Bespoke module
2. Key-based bespoke - API Wrapper (fairly secure)
   1. Query Rewrite
   2. Query Filter
3. Separate Servers (super secure)

Other

1. Network gateways
2. Searchable data and encrypted data
3. Backups of classified information

Access Control in ES ⌘

Shield ⌘

• ES plugin
• not free
• index level
• document level
• field level
• URL based access
• audit trail
• SSL/TSL encription (without cluster)

more https://www.elastic.co/guide/en/shield/current/configuring-rbac.html

Shield: Index Level ⌘

{
   "current_year_read": {
      "cluster":[],
      "indices":[{
         "names":["current_year"],
         "privileges":["read"]}],
      "run_as":[]
   }
}

Shield: Document Level ⌘

POST /_shield/role/my_dls_role
{
  "indices": [
    {
      "names": [ "index1", "index2" ],
      "privileges": ["read"], 
      "query": {"term" : {"department_id" : "12"}} 
    }
  ]
}

Shield: Field Level ⌘

POST /_shield/role/my_fls_role
{
  "indices": [
    {
      "names": [ "index1", "index2" ],
      "privileges": ["read"], 
      "fields": [ "title", "body" ]
    }
  ]
}

cannot control other modules or upgrades - no way of assuring security

Access Control in ES - pros and cons ⌘

Pros

• no need of separate code
• arguably the fastest method

Cons

• only standard API comply, other modules simply ignore Shield
• upgrading and compatibility problems
• hard to test

Other in ES

• Scripts in ES
  • Versioning, unit testing?

API Wrapper ⌘

• Query Rewrite
• Result Filter
• Aggregated Result Problem

Pros

• Existing permission system (e.g. application permission system, LDAP, etc...) can be implmeneted

Cons

• Needs to be develop
• Speed (arguably)

Query Rewrite⌘

GET _search
{
   "query": {
      "match_all": {}
   }
}

BECOMES

GET _search {
  "query": {
    "bool": {
      "must": {
        "match_all": {}
      },
      "filter": {
        "term": {
          "roles": "managers"
        }}}}}

Query Rewrite⌘

Pros

1. Very fast (almost no impact on performance)
2. Upgrading ES have almost no impact on the logic and security
3. Full control on how queries are rewritten
4. Bespoke way handling aggregation (e.g. allow users to see totals of sales in departments, but not concrete documents)

Cons

1. Becoming more complex with complex queries (e.g. aggregation)
2. May be tricky to test

Filter API Wrapper ⌘

• Filtering takes place in the API Wrapper

Pros

• Full control over results
• Very easy to test

Drawbacks

• Poor Performance

Elasticsearch Performance Testing with JMeter ⌘

• JMeter - example with recording post and playing them up
• Use Chrome plugin

Category:JMeter