Authentication and security

  • Firewall port 9300 for intra-cluster connections only
    • Puppet exported rule with the tag set from a hiera secret
  • Apache on the master node
    • 443 - https, cern SSO, read-only, authorization on cern e-groups
      • allowed adding kibana dashboards
      • TODO? one e-group to add dashboards, another - read-only. May be difficult
    • 9201 - http, basic auth, read-only, users, groups, passwords in hiera
      • TODO: https, need cooperation from clients. What clients?
    • 9202 - http, basic auth, full access, users, groups, passwords in hiera
      • TODO: https, need cooperation from clients (e.g. MIG writer)
    • all ports proxy towards localhost:9200
    • r/o enforced with mod_rewrite on http method + location * TODO: forbid scripted searches (unsafe) script.disable_dynamic: true * TODO? index-level separation
    • needs: forbid bulk requests location override rest.action.multi.allow_explicit_index: false


  • We need Apache for Shibboleth anyway
  • Apache will probably allow cert-based authentication
  • Jetty's authorization is location-based anyway, can be replicated in Apache.
  • At first a simple restriction based on HTTP method is enough:
    • "writing" GETs can only flush indices and clear caches. In a strictest sense these are write operations, but not really dangerous.
    • "reading" POSTs are provided for compatibility with clients that don't support GETs with payload. We have predictable clients so we don't need these.
      • actually Kibana does use POST /_search. Location filter will be necessary.
    • in the first pass we don't make a distinction between administrative POSTs (controlling the cluster) and data write POSTs

Jetty plugin

 /usr/share/elasticsearch/bin/plugin \
                      -url \
                      -install elasticsearch-jetty 

Problem: Kibana stops working.

XMLHttpRequest cannot load http://dashb-es:9200/_all/_search. Request header field Content-Type is not allowed by Access-Control-Allow-Headers. 
Will need a "real" webserver to solve it with CORS:!topic/elasticsearch-jetty/L8x3dBM3TEg

Either that, or instead of using downloaded Kibana, put it on the same domain, which also means installing a webserver. Correction: can also use the aimon team method and install a kibana fork as an Elasticsearch plugin:

/usr/share/elasticsearch/bin/plugin -url -i kibana

We would want Apache eventually for SSO integration anyway.

Important steps

Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r5 - 2014-05-26 - IvanKadochnikov
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LCG All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback