# REST Security Surface Area and Hardening ElasticSearch Installs
**URL:** https://discuss.elastic.co/t/rest-security-surface-area-and-hardening-elasticsearch-installs/10858
**Category:** Elasticsearch
**Created:** [February 23, 2013, 1:11am UTC](https://discuss.elastic.co/t/rest-security-surface-area-and-hardening-elasticsearch-installs/10858 "2013-02-23T01:11:01Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@Darren\_Rush](https://discuss.elastic.co/u/Darren_Rush)
#### Post date: [February 23, 2013, 1:11am UTC](https://discuss.elastic.co/t/rest-security-surface-area-and-hardening-elasticsearch-installs/10858/1 "2013-02-23T01:11:01Z")
Now that ES is in the big leagues, I'd like to re-open a discussion about
security, hardening and operational issues. Specifically, the position up
until this point on security and authentication of any kind has been 'stick
a proxy out front'. Unfortunately, the diversity of approaches to tackling
this don't create any single methodology that would converge toward a
robust solution in the coming years.
Cutting my opinions short let me propose a couple of very specific
recommendations to the group:
1. Refactor REST routes so that a VERY simple ruleset may be applied to
differentiate Read/Write access.
Use Case:
- Allow any user to issue search requests without authentication
- Allow any authenticated user to access ANY endpoint
Problem:
- To implement this, one might want to pass all GET request through, and
force authentication for all other verbs. However, searches can and are
often required to be issued as POSTS via \_search and \_msearch, so these
specific strings would need to be detected in the URL as well. It is
possible that new features such as 'Update By Query' might also create more
conflicts of R/W within the POST verb segment of routes.
Possible Solution:
- Require all searches (\_search and \_msearch) to be issued via GET,
ensuring long URLs are supported (Solr supports up to 64KB even though IE
has a 2K limit)
- Publish a simple logical ruleset that would 'Secure' an ES instance
1. Replace Netty with Jetty and minimize configuration changes to enable
HTTPS and Basic Authentication for simple install scenarios
2. Apply the now easy to implement and easy to verify 'rules' from #1
above, to allow a fresh ES install to set auth requirements for Searches,
R/W access and Configuration changes, with 3 roles [user, editor, admin]
where an array of user/pass combinations can be assigned to these roles (or
none) to allow for the diverse type of access that is required. This can
be used in development or single-server production deployments.
3. ES should either develop or make a 'preferred' recommendation for a
Proxy/Load Balancer with a provided sample configuration. Managing
backends from a LB is a non-trivial problem, and intelligent integration
with proxies is a highly desirable feature. Moreover there seem to be
shortcomings with almost every option out there currently. For example, my
preferred choice for a LB/Proxy would be Varnish. Varnish can easily
provide HTTPS if needed, as well as a simple auth system. However the
rules to actually secure ES implemented in VCL would be lengthy and error
prone. Moreover the caching features of Varnish are cannot be leveraged
because Varnish will not use POST bodies as part of a cache key in any
default configuration. (Caching of common queries is highly desirable in
many use cases - but I'll leave that for another post).
It is totally possible that some of this is in process, has already been
discussed, or already been solved, but I've not yet come across the
appropriate material. Please help educate me if that is the case,
otherwise, I hope this helps create some lively conversation around these
and related topics.
D
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
---
### Author:  [@dakrone](https://discuss.elastic.co/u/dakrone)
#### Post date: [February 23, 2013, 1:14am UTC](https://discuss.elastic.co/t/rest-security-surface-area-and-hardening-elasticsearch-installs/10858/2 "2013-02-23T01:14:18Z")
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2/22/13 6:11 PM, Darren Rush wrote:
> Now that ES is in the big leagues, I'd like to re-open a
> discussion about security, hardening and operational issues.
> Specifically, the position up until this point on security and
> authentication of any kind has been 'stick a proxy out front'.
> Unfortunately, the diversity of approaches to tackling this don't
> create any single methodology that would converge toward a robust
> solution in the coming years.
>
> Cutting my opinions short let me propose a couple of very specific
> recommendations to the group:
>
> 1. Refactor REST routes so that a VERY simple ruleset may be
> applied to differentiate Read/Write access. Use Case: - Allow any
> user to issue search requests without authentication - Allow any
> authenticated user to access ANY endpoint
>
> Problem: - To implement this, one might want to pass all GET
> request through, and force authentication for all other verbs.
> However, searches can and are often required to be issued as POSTS
> via \_search and \_msearch, so these specific strings would need to
> be detected in the URL as well. It is possible that new features
> such as 'Update By Query' might also create more conflicts of R/W
> within the POST verb segment of routes.
>
> Possible Solution: - Require all searches (\_search and \_msearch) to
> be issued via GET, ensuring long URLs are supported (Solr supports
> up to 64KB even though IE has a 2K limit) - Publish a simple
> logical ruleset that would 'Secure' an ES instance
>
> 1. Replace Netty with Jetty and minimize configuration changes to
> enable HTTPS and Basic Authentication for simple install scenarios
>
> 2. Apply the now easy to implement and easy to verify 'rules' from
> #1 above, to allow a fresh ES install to set auth requirements for
> Searches, R/W access and Configuration changes, with 3 roles
> [user, editor, admin] where an array of user/pass combinations can
> be assigned to these roles (or none) to allow for the diverse type
> of access that is required. This can be used in development or
> single-server production deployments.
>
> 3. ES should either develop or make a 'preferred' recommendation
> for a Proxy/Load Balancer with a provided sample configuration.
> Managing backends from a LB is a non-trivial problem, and
> intelligent integration with proxies is a highly desirable feature.
> Moreover there seem to be shortcomings with almost every option out
> there currently. For example, my preferred choice for a LB/Proxy
> would be Varnish. Varnish can easily provide HTTPS if needed, as
> well as a simple auth system. However the rules to actually secure
> ES implemented in VCL would be lengthy and error prone. Moreover
> the caching features of Varnish are cannot be leveraged because
> Varnish will not use POST bodies as part of a cache key in any
> default configuration. (Caching of common queries is highly
> desirable in many use cases - but I'll leave that for another
> post).
>
> It is totally possible that some of this is in process, has already
> been discussed, or already been solved, but I've not yet come
> across the appropriate material. Please help educate me if that is
> the case, otherwise, I hope this helps create some lively
> conversation around these and related topics.
>
> D
Some of these topics, notably requiring authentication for REST
operations and replacing Netty with Jetty are already implemented in
the elasticsearch-jetty[1](https://github.com/sonian/elasticsearch-jetty/) plugin.
Is there a reason why something like this should be inside of
Elasticsearch itself, rather than a plugin?
;; Lee Hinman
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Darwin)
Comment: Using GnuPG with Thunderbird - [http://www.enigmail.net/](http://www.enigmail.net/)
iQIcBAEBAgAGBQJRKBfqAAoJEJ1kZdQ6zsrgJIwP/0C1Qpb9KHcJM9eeLo9UADj9
O01I7Dn3lz8ZXTc+iYA8nM8QBYl0vC7O966UiLc5UNtwIroXNT4yhrWNw5O7ctLu
c+TvQ/RR2kJvc9EW9aSyj9BnCO7QYUl1RDWAhUTuvEvbdyxmC60zLG+lEd7tRQrK
no6i4zwIMgwbnMDGC/2OJhQP4kg0lM6UbcWFJjN1HcBU5lJEXu5ng7P+JZNdrrBZ
fbCoXt22ix78lBrecfI3ViQEgd3dyr3Dy5FQfxPcqD7xvBUNKeGpyvHS9kRozNSJ
gMtnjMKyp/BvtLYjw3Qs4RLC5c8TglEdv4V4TgNmqMOyJGS2opwT8485XWV714tm
sOHewU/v2mEWVTnAeu+3BUxRAWz2iLN47ti+rtsrddMMetFC6r5HFtvWF+4TsnSp
QagaA2hRZJmAI1z+9f8BB+1vJNlwPTFglTAm6g7Ppk2Td5ss5QjuWVFpm0w6xnn/
9sr6QoLEuKL5JtQA6Ke50Wu23VghNu9uxJP6R+T5qVNYls+sjU37G2LmPVRlKs5n
jbIpAGUvrrS0xhY02fbiCzi26EU/3JtmeNQzoovsL/t9duj3mkpgvfVpoC98EXiH
XGdIYC675VH7nbqBEv895Wb61E3FNNJaFhy8V8wqTvCmJ0/46/v/kcbWVB2qLY74
TYzR5vw0Xa9q7tPE0EeN
=jpse
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
---
### Author:  [@Hendrik](https://discuss.elastic.co/u/Hendrik)
#### Post date: [October 23, 2013, 3:36pm UTC](https://discuss.elastic.co/t/rest-security-surface-area-and-hardening-elasticsearch-installs/10858/3 "2013-10-23T15:36:37Z")
> **[GitHub - salyh/elasticsearch-security-plugin: Kerberos, LDAP, Active...](https://github.com/salyh/elasticsearch-security-plugin)**
>
> Kerberos, LDAP, Active Directory, PKI/SSL/TLS and host/ip based ACL coarse-grained and document level security for elasticsearch (Authentication, Authorization, Auth, Spnego, ACL, Mutual authentica...
Am Samstag, 23. Februar 2013 02:11:01 UTC+1 schrieb Darren Rush:
> Now that ES is in the big leagues, I'd like to re-open a discussion about
> security, hardening and operational issues. Specifically, the position up
> until this point on security and authentication of any kind has been 'stick
> a proxy out front'. Unfortunately, the diversity of approaches to tackling
> this don't create any single methodology that would converge toward a
> robust solution in the coming years.
>
> Cutting my opinions short let me propose a couple of very specific
> recommendations to the group:
>
> 1. Refactor REST routes so that a VERY simple ruleset may be applied to
> differentiate Read/Write access.
> Use Case:
>
> - Allow any user to issue search requests without authentication
> - Allow any authenticated user to access ANY endpoint
>
> Problem:
>
> - To implement this, one might want to pass all GET request through, and
> force authentication for all other verbs. However, searches can and are
> often required to be issued as POSTS via \_search and \_msearch, so these
> specific strings would need to be detected in the URL as well. It is
> possible that new features such as 'Update By Query' might also create more
> conflicts of R/W within the POST verb segment of routes.
>
> Possible Solution:
>
> - Require all searches (\_search and \_msearch) to be issued via GET,
> ensuring long URLs are supported (Solr supports up to 64KB even though IE
> has a 2K limit)
> - Publish a simple logical ruleset that would 'Secure' an ES instance
>
> 1. Replace Netty with Jetty and minimize configuration changes to enable
> HTTPS and Basic Authentication for simple install scenarios
>
> 2. Apply the now easy to implement and easy to verify 'rules' from #1
> above, to allow a fresh ES install to set auth requirements for Searches,
> R/W access and Configuration changes, with 3 roles [user, editor, admin]
> where an array of user/pass combinations can be assigned to these roles (or
> none) to allow for the diverse type of access that is required. This can
> be used in development or single-server production deployments.
>
> 3. ES should either develop or make a 'preferred' recommendation for a
> Proxy/Load Balancer with a provided sample configuration. Managing
> backends from a LB is a non-trivial problem, and intelligent integration
> with proxies is a highly desirable feature. Moreover there seem to be
> shortcomings with almost every option out there currently. For example, my
> preferred choice for a LB/Proxy would be Varnish. Varnish can easily
> provide HTTPS if needed, as well as a simple auth system. However the
> rules to actually secure ES implemented in VCL would be lengthy and error
> prone. Moreover the caching features of Varnish are cannot be leveraged
> because Varnish will not use POST bodies as part of a cache key in any
> default configuration. (Caching of common queries is highly desirable in
> many use cases - but I'll leave that for another post).
>
> It is totally possible that some of this is in process, has already been
> discussed, or already been solved, but I've not yet come across the
> appropriate material. Please help educate me if that is the case,
> otherwise, I hope this helps create some lively conversation around these
> and related topics.
>
> D
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
---
### Author:  [@Darren\_Rush](https://discuss.elastic.co/u/Darren_Rush)
#### Post date: [October 24, 2013, 10:32pm UTC](https://discuss.elastic.co/t/rest-security-surface-area-and-hardening-elasticsearch-installs/10858/4 "2013-10-24T22:32:13Z")
Hendrik,
Looks promising! Looking forward to some overview docs that describe the
proper config and first use.
Thanks,
Darren
On Wed, Oct 23, 2013 at 8:36 AM, Hendrik [h.j.saly@googlemail.com](mailto:h.j.saly@googlemail.com) wrote:
> [GitHub - salyh/elasticsearch-security-plugin: Kerberos, LDAP, Active Directory, PKI/SSL/TLS and host/ip based ACL coarse-grained and document level security for elasticsearch (Authentication, Authorization, Auth, Spnego, ACL, Mutual authentication)](https://github.com/salyh/elasticsearch-security-plugin)
>
> Am Samstag, 23. Februar 2013 02:11:01 UTC+1 schrieb Darren Rush:
>
> > Now that ES is in the big leagues, I'd like to re-open a discussion about
> > security, hardening and operational issues. Specifically, the position up
> > until this point on security and authentication of any kind has been 'stick
> > a proxy out front'. Unfortunately, the diversity of approaches to tackling
> > this don't create any single methodology that would converge toward a
> > robust solution in the coming years.
> >
> > Cutting my opinions short let me propose a couple of very specific
> > recommendations to the group:
> >
> > 1. Refactor REST routes so that a VERY simple ruleset may be applied to
> > differentiate Read/Write access.
> > Use Case:
> >
> > - Allow any user to issue search requests without authentication
> > - Allow any authenticated user to access ANY endpoint
> >
> > Problem:
> >
> > - To implement this, one might want to pass all GET request through,
> > and force authentication for all other verbs. However, searches can and
> > are often required to be issued as POSTS via \_search and \_msearch, so these
> > specific strings would need to be detected in the URL as well. It is
> > possible that new features such as 'Update By Query' might also create more
> > conflicts of R/W within the POST verb segment of routes.
> >
> > Possible Solution:
> >
> > - Require all searches (\_search and \_msearch) to be issued via GET,
> > ensuring long URLs are supported (Solr supports up to 64KB even though IE
> > has a 2K limit)
> > - Publish a simple logical ruleset that would 'Secure' an ES instance
> >
> > 1. Replace Netty with Jetty and minimize configuration changes to enable
> > HTTPS and Basic Authentication for simple install scenarios
> >
> > 2. Apply the now easy to implement and easy to verify 'rules' from #1
> > above, to allow a fresh ES install to set auth requirements for Searches,
> > R/W access and Configuration changes, with 3 roles [user, editor, admin]
> > where an array of user/pass combinations can be assigned to these roles (or
> > none) to allow for the diverse type of access that is required. This can
> > be used in development or single-server production deployments.
> >
> > 3. ES should either develop or make a 'preferred' recommendation for a
> > Proxy/Load Balancer with a provided sample configuration. Managing
> > backends from a LB is a non-trivial problem, and intelligent integration
> > with proxies is a highly desirable feature. Moreover there seem to be
> > shortcomings with almost every option out there currently. For example, my
> > preferred choice for a LB/Proxy would be Varnish. Varnish can easily
> > provide HTTPS if needed, as well as a simple auth system. However the
> > rules to actually secure ES implemented in VCL would be lengthy and error
> > prone. Moreover the caching features of Varnish are cannot be leveraged
> > because Varnish will not use POST bodies as part of a cache key in any
> > default configuration. (Caching of common queries is highly desirable in
> > many use cases - but I'll leave that for another post).
> >
> > It is totally possible that some of this is in process, has already been
> > discussed, or already been solved, but I've not yet come across the
> > appropriate material. Please help educate me if that is the case,
> > otherwise, I hope this helps create some lively conversation around these
> > and related topics.
> >
> > D
> >
> > --
> > You received this message because you are subscribed to a topic in the
> > Google Groups "elasticsearch" group.
> > To unsubscribe from this topic, visit
> > [https://groups.google.com/d/topic/elasticsearch/eBp5OlbkXd0/unsubscribe](https://groups.google.com/d/topic/elasticsearch/eBp5OlbkXd0/unsubscribe).
> > To unsubscribe from this group and all its topics, send an email to
> > [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
>
> For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
--
Let's Meet: _[http://meetme.so/DarrenRush](http://meetme.so/DarrenRush)_ [http://meetme.so/DarrenRush](http://meetme.so/DarrenRush)
Find me online: _Twitter_ [http://twitter.com/darrenrush](http://twitter.com/darrenrush) |
_Blog_[http://darrenrush.com](http://darrenrush.com)|
_LinkedIn [http://www.linkedin.com/in/darrenrush](http://www.linkedin.com/in/darrenrush)_
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
---
### Author:  [@Hendrik](https://discuss.elastic.co/u/Hendrik)
#### Post date: [October 30, 2013, 2:56pm UTC](https://discuss.elastic.co/t/rest-security-surface-area-and-hardening-elasticsearch-installs/10858/5 "2013-10-30T14:56:34Z")
>
Am Freitag, 25. Oktober 2013 00:32:13 UTC+2 schrieb Darren Rush:
> Hendrik,
>
> Looks promising! Looking forward to some overview docs that describe the
> proper config and first use.
>
> Thanks,
> Darren
>
> On Wed, Oct 23, 2013 at 8:36 AM, Hendrik \<[h.j....@googlemail.com](mailto:h.j....@googlemail.com)\
>
> > wrote:
>
> > [GitHub - salyh/elasticsearch-security-plugin: Kerberos, LDAP, Active Directory, PKI/SSL/TLS and host/ip based ACL coarse-grained and document level security for elasticsearch (Authentication, Authorization, Auth, Spnego, ACL, Mutual authentication)](https://github.com/salyh/elasticsearch-security-plugin)
> >
> > Am Samstag, 23. Februar 2013 02:11:01 UTC+1 schrieb Darren Rush:
> >
> > > Now that ES is in the big leagues, I'd like to re-open a discussion
> > > about security, hardening and operational issues. Specifically, the
> > > position up until this point on security and authentication of any kind has
> > > been 'stick a proxy out front'. Unfortunately, the diversity of approaches
> > > to tackling this don't create any single methodology that would converge
> > > toward a robust solution in the coming years.
> > >
> > > Cutting my opinions short let me propose a couple of very specific
> > > recommendations to the group:
> > >
> > > 1. Refactor REST routes so that a VERY simple ruleset may be applied to
> > > differentiate Read/Write access.
> > > Use Case:
> > >
> > > - Allow any user to issue search requests without authentication
> > > - Allow any authenticated user to access ANY endpoint
> > >
> > > Problem:
> > >
> > > - To implement this, one might want to pass all GET request through,
> > > and force authentication for all other verbs. However, searches can and
> > > are often required to be issued as POSTS via \_search and \_msearch, so these
> > > specific strings would need to be detected in the URL as well. It is
> > > possible that new features such as 'Update By Query' might also create more
> > > conflicts of R/W within the POST verb segment of routes.
> > >
> > > Possible Solution:
> > >
> > > - Require all searches (\_search and \_msearch) to be issued via GET,
> > > ensuring long URLs are supported (Solr supports up to 64KB even though IE
> > > has a 2K limit)
> > > - Publish a simple logical ruleset that would 'Secure' an ES instance
> > >
> > > 1. Replace Netty with Jetty and minimize configuration changes to enable
> > > HTTPS and Basic Authentication for simple install scenarios
> > >
> > > 2. Apply the now easy to implement and easy to verify 'rules' from #1
> > > above, to allow a fresh ES install to set auth requirements for Searches,
> > > R/W access and Configuration changes, with 3 roles [user, editor, admin]
> > > where an array of user/pass combinations can be assigned to these roles (or
> > > none) to allow for the diverse type of access that is required. This can
> > > be used in development or single-server production deployments.
> > >
> > > 3. ES should either develop or make a 'preferred' recommendation for a
> > > Proxy/Load Balancer with a provided sample configuration. Managing
> > > backends from a LB is a non-trivial problem, and intelligent integration
> > > with proxies is a highly desirable feature. Moreover there seem to be
> > > shortcomings with almost every option out there currently. For example, my
> > > preferred choice for a LB/Proxy would be Varnish. Varnish can easily
> > > provide HTTPS if needed, as well as a simple auth system. However the
> > > rules to actually secure ES implemented in VCL would be lengthy and error
> > > prone. Moreover the caching features of Varnish are cannot be leveraged
> > > because Varnish will not use POST bodies as part of a cache key in any
> > > default configuration. (Caching of common queries is highly desirable in
> > > many use cases - but I'll leave that for another post).
> > >
> > > It is totally possible that some of this is in process, has already been
> > > discussed, or already been solved, but I've not yet come across the
> > > appropriate material. Please help educate me if that is the case,
> > > otherwise, I hope this helps create some lively conversation around these
> > > and related topics.
> > >
> > > D
> > >
> > > --
> > > You received this message because you are subscribed to a topic in the
> > > Google Groups "elasticsearch" group.
> > > To unsubscribe from this topic, visit
> > > [https://groups.google.com/d/topic/elasticsearch/eBp5OlbkXd0/unsubscribe](https://groups.google.com/d/topic/elasticsearch/eBp5OlbkXd0/unsubscribe).
> > > To unsubscribe from this group and all its topics, send an email to
> > > [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \.
> >
> > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
>
> --
> Let's Meet: _[http://meetme.so/DarrenRush](http://meetme.so/DarrenRush)_ [http://meetme.so/DarrenRush](http://meetme.so/DarrenRush)
> Find me online: _Twitter_ [http://twitter.com/darrenrush](http://twitter.com/darrenrush) | _Blog_[http://darrenrush.com](http://darrenrush.com)|
> _LinkedIn [http://www.linkedin.com/in/darrenrush](http://www.linkedin.com/in/darrenrush)_
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
---
### Author:  [@Hassan\_Schroeder](https://discuss.elastic.co/u/Hassan_Schroeder)
#### Post date: [October 30, 2013, 5:37pm UTC](https://discuss.elastic.co/t/rest-security-surface-area-and-hardening-elasticsearch-installs/10858/6 "2013-10-30T17:37:04Z")
On Wed, Oct 30, 2013 at 7:56 AM, Hendrik [h.j.saly@googlemail.com](mailto:h.j.saly@googlemail.com) wrote:
> [https://github.com/salyh/elasticsearch-security-plugin/blob/master/README.md](https://github.com/salyh/elasticsearch-security-plugin/blob/master/README.md)
Uh, well. I'm afraid that's not particularly helpful, at least to me.
The installation instructions are inexact and appear to be wrong; I
finally got (through guesswork via the error messages) as far as
0:07 /usr/local/elasticsearch-0.90.5 (master)$ ./bin/plugin -install
salyh/elasticsearch-security-plugin
-\> Installing salyh/elasticsearch-security-plugin...
Trying [https://github.com/salyh/elasticsearch-security-plugin/archive/master.zip](https://github.com/salyh/elasticsearch-security-plugin/archive/master.zip)...
Downloading ....DONE
Installed salyh/elasticsearch-security-plugin into
/usr/local/elasticsearch-0.90.5/plugins/security-plugin
10:07 /usr/local/elasticsearch-0.90.5 (master)$ ls plugins/
total 0
drwxr-xr-x 2 hassan staff 68 Oct 30 10:07 ./
drwxr-xr-x 11 hassan staff 374 Oct 30 10:03 ../
10:07 /usr/local/elasticsearch-0.90.5 (master)$ ./bin/plugin --list
Installed plugins:
- No plugin detected in /usr/local/elasticsearch-0.90.5/plugins
10:08 /usr/local/elasticsearch-0.90.5 (master)$
Which doesn't seem promising. 🙂
Adding the "enable security plugin" line verbatim
http.type:org.elasticsearch.plugins.security.http.netty.NettyHttpServerTransportModule
to elasticsearch.yml and trying `./bin/plugin --list` results in
Exception in thread "main"
org.elasticsearch.common.settings.SettingsException: Failed to load
settings from [file:/usr/local/elasticsearch-0.90.5/config/elasticsearch.yml]
at org.elasticsearch.common.settings.ImmutableSettings$Builder.loadFromStream(ImmutableSettings.java:774)
at org.elasticsearch.common.settings.ImmutableSettings$Builder.loadFromUrl(ImmutableSettings.java:758)
at org.elasticsearch.node.internal.InternalSettingsPreparer.prepareSettings(InternalSettingsPreparer.java:74)
at org.elasticsearch.plugins.PluginManager.main(PluginManager.java:296)
Caused by: org.elasticsearch.ElasticSearchParseException: malformed,
expected settings to start with 'object', instead was [VALUE\_STRING]
at org.elasticsearch.common.settings.loader.XContentSettingsLoader.load(XContentSettingsLoader.java:71)
at org.elasticsearch.common.settings.loader.XContentSettingsLoader.load(XContentSettingsLoader.java:46)
at org.elasticsearch.common.settings.loader.YamlSettingsLoader.load(YamlSettingsLoader.java:41)
at org.elasticsearch.common.settings.ImmutableSettings$Builder.loadFromStream(ImmutableSettings.java:771)
... 3 more
Some further direction on how to install and configure this would be
much appreciated!
--
Hassan Schroeder ------------------------ [hassan.schroeder@gmail.com](mailto:hassan.schroeder@gmail.com)
[Hassan Schroeder | about.me](http://about.me/hassanschroeder)
twitter: @hassan
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
---
### Author:  [@Hendrik](https://discuss.elastic.co/u/Hendrik)
#### Post date: [October 31, 2013, 9:14am UTC](https://discuss.elastic.co/t/rest-security-surface-area-and-hardening-elasticsearch-installs/10858/7 "2013-10-31T09:14:02Z")
fixed, see [GitHub - salyh/elasticsearch-security-plugin: Kerberos, LDAP, Active Directory, PKI/SSL/TLS and host/ip based ACL coarse-grained and document level security for elasticsearch (Authentication, Authorization, Auth, Spnego, ACL, Mutual authentication)](https://github.com/salyh/elasticsearch-security-plugin)
Am Mittwoch, 30. Oktober 2013 18:37:04 UTC+1 schrieb hassan:
> On Wed, Oct 30, 2013 at 7:56 AM, Hendrik \<[h.j....@googlemail.com](mailto:h.j....@googlemail.com)\\>
> wrote:
>
> >
>
> [https://github.com/salyh/elasticsearch-security-plugin/blob/master/README.md](https://github.com/salyh/elasticsearch-security-plugin/blob/master/README.md)
>
> Uh, well. I'm afraid that's not particularly helpful, at least to me.
>
> The installation instructions are inexact and appear to be wrong; I
> finally got (through guesswork via the error messages) as far as
>
> 0:07 /usr/local/elasticsearch-0.90.5 (master)$ ./bin/plugin -install
> salyh/elasticsearch-security-plugin
> -\> Installing salyh/elasticsearch-security-plugin...
> Trying
> [https://github.com/salyh/elasticsearch-security-plugin/archive/master.zip](https://github.com/salyh/elasticsearch-security-plugin/archive/master.zip)...
>
> Downloading ....DONE
> Installed salyh/elasticsearch-security-plugin into
> /usr/local/elasticsearch-0.90.5/plugins/security-plugin
> 10:07 /usr/local/elasticsearch-0.90.5 (master)$ ls plugins/
> total 0
> drwxr-xr-x 2 hassan staff 68 Oct 30 10:07 ./
> drwxr-xr-x 11 hassan staff 374 Oct 30 10:03 ../
> 10:07 /usr/local/elasticsearch-0.90.5 (master)$ ./bin/plugin --list
> Installed plugins:
> - No plugin detected in /usr/local/elasticsearch-0.90.5/plugins
> 10:08 /usr/local/elasticsearch-0.90.5 (master)$
>
> Which doesn't seem promising. 🙂
>
> Adding the "enable security plugin" line verbatim
>
> http.type:org.elasticsearch.plugins.security.http.netty.NettyHttpServerTransportModule
>
> to elasticsearch.yml and trying `./bin/plugin --list` results in
>
> Exception in thread "main"
> org.elasticsearch.common.settings.SettingsException: Failed to load
> settings from
> [file:/usr/local/elasticsearch-0.90.5/config/elasticsearch.yml]
> at
> org.elasticsearch.common.settings.ImmutableSettings$Builder.loadFromStream(ImmutableSettings.java:774)
>
> at
> org.elasticsearch.common.settings.ImmutableSettings$Builder.loadFromUrl(ImmutableSettings.java:758)
>
> at
> org.elasticsearch.node.internal.InternalSettingsPreparer.prepareSettings(InternalSettingsPreparer.java:74)
>
> at org.elasticsearch.plugins.PluginManager.main(PluginManager.java:296)
> Caused by: org.elasticsearch.ElasticSearchParseException: malformed,
> expected settings to start with 'object', instead was [VALUE\_STRING]
> at
> org.elasticsearch.common.settings.loader.XContentSettingsLoader.load(XContentSettingsLoader.java:71)
>
> at
> org.elasticsearch.common.settings.loader.XContentSettingsLoader.load(XContentSettingsLoader.java:46)
>
> at
> org.elasticsearch.common.settings.loader.YamlSettingsLoader.load(YamlSettingsLoader.java:41)
>
> at
> org.elasticsearch.common.settings.ImmutableSettings$Builder.loadFromStream(ImmutableSettings.java:771)
>
> ... 3 more
>
> Some further direction on how to install and configure this would be
> much appreciated!
>
> --
> Hassan Schroeder ------------------------ [hassan.s...@gmail.com](mailto:hassan.s...@gmail.com)\
> [Hassan Schroeder | about.me](http://about.me/hassanschroeder)
> twitter: @hassan
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
---
### Author:  [@Hassan\_Schroeder](https://discuss.elastic.co/u/Hassan_Schroeder)
#### Post date: [October 31, 2013, 2:45pm UTC](https://discuss.elastic.co/t/rest-security-surface-area-and-hardening-elasticsearch-installs/10858/8 "2013-10-31T14:45:30Z")
On Thu, Oct 31, 2013 at 2:14 AM, Hendrik [h.j.saly@googlemail.com](mailto:h.j.saly@googlemail.com) wrote:
> fixed, see [GitHub - salyh/elasticsearch-security-plugin: Kerberos, LDAP, Active Directory, PKI/SSL/TLS and host/ip based ACL coarse-grained and document level security for elasticsearch (Authentication, Authorization, Auth, Spnego, ACL, Mutual authentication)](https://github.com/salyh/elasticsearch-security-plugin)
Better,
07:23 /usr/local/elasticsearch-0.90.5 (master)$ bin/plugin --list
Installed plugins:
- security-plugin-0.0.1.Beta1
but adding the "Enable ..." line still causes
07:24 /usr/local/elasticsearch-0.90.5/config (master)$ bin/plugin --list
Exception in thread "main"
org.elasticsearch.common.settings.SettingsException: Failed to load
settings from [file:/usr/local/elasticsearch-0.90.5/config/elasticsearch.yml]
at org.elasticsearch.common.settings.ImmutableSettings$Builder.loadFromStream(ImmutableSettings.java:774)
at org.elasticsearch.common.settings.ImmutableSettings$Builder.loadFromUrl(ImmutableSettings.java:758)
at org.elasticsearch.node.internal.InternalSettingsPreparer.prepareSettings(InternalSettingsPreparer.java:74)
at org.elasticsearch.plugins.PluginManager.main(PluginManager.java:296)
Caused by: org.elasticsearch.ElasticSearchParseException: malformed,
expected settings to start with 'object', instead was [VALUE\_STRING]
at org.elasticsearch.common.settings.loader.XContentSettingsLoader.load(XContentSettingsLoader.java:71)
at org.elasticsearch.common.settings.loader.XContentSettingsLoader.load(XContentSettingsLoader.java:46)
at org.elasticsearch.common.settings.loader.YamlSettingsLoader.load(YamlSettingsLoader.java:41)
at org.elasticsearch.common.settings.ImmutableSettings$Builder.loadFromStream(ImmutableSettings.java:771)
... 3 more
Is there a generic guide somewhere to configuring ES plugins? As
this is the first one I've used, I have nothing to compare to...
--
Hassan Schroeder ------------------------ [hassan.schroeder@gmail.com](mailto:hassan.schroeder@gmail.com)
[Hassan Schroeder | about.me](http://about.me/hassanschroeder)
twitter: @hassan
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
---
### Author:  [@Hendrik](https://discuss.elastic.co/u/Hendrik)
#### Post date: [October 31, 2013, 2:56pm UTC](https://discuss.elastic.co/t/rest-security-surface-area-and-hardening-elasticsearch-installs/10858/9 "2013-10-31T14:56:15Z")
can you please post your elasticsearch.yml config file?
Am Donnerstag, 31. Oktober 2013 15:45:30 UTC+1 schrieb hassan:
> On Thu, Oct 31, 2013 at 2:14 AM, Hendrik \<[h.j....@googlemail.com](mailto:h.j....@googlemail.com)\\>
> wrote:
>
> > fixed, see [GitHub - salyh/elasticsearch-security-plugin: Kerberos, LDAP, Active Directory, PKI/SSL/TLS and host/ip based ACL coarse-grained and document level security for elasticsearch (Authentication, Authorization, Auth, Spnego, ACL, Mutual authentication)](https://github.com/salyh/elasticsearch-security-plugin)
>
> Better,
>
> 07:23 /usr/local/elasticsearch-0.90.5 (master)$ bin/plugin --list
> Installed plugins:
> - security-plugin-0.0.1.Beta1
>
> but adding the "Enable ..." line still causes
>
> 07:24 /usr/local/elasticsearch-0.90.5/config (master)$ bin/plugin --list
> Exception in thread "main"
> org.elasticsearch.common.settings.SettingsException: Failed to load
> settings from
> [file:/usr/local/elasticsearch-0.90.5/config/elasticsearch.yml]
> at
> org.elasticsearch.common.settings.ImmutableSettings$Builder.loadFromStream(ImmutableSettings.java:774)
>
> at
> org.elasticsearch.common.settings.ImmutableSettings$Builder.loadFromUrl(ImmutableSettings.java:758)
>
> at
> org.elasticsearch.node.internal.InternalSettingsPreparer.prepareSettings(InternalSettingsPreparer.java:74)
>
> at org.elasticsearch.plugins.PluginManager.main(PluginManager.java:296)
> Caused by: org.elasticsearch.ElasticSearchParseException: malformed,
> expected settings to start with 'object', instead was [VALUE\_STRING]
> at
> org.elasticsearch.common.settings.loader.XContentSettingsLoader.load(XContentSettingsLoader.java:71)
>
> at
> org.elasticsearch.common.settings.loader.XContentSettingsLoader.load(XContentSettingsLoader.java:46)
>
> at
> org.elasticsearch.common.settings.loader.YamlSettingsLoader.load(YamlSettingsLoader.java:41)
>
> at
> org.elasticsearch.common.settings.ImmutableSettings$Builder.loadFromStream(ImmutableSettings.java:771)
>
> ... 3 more
>
> Is there a generic guide somewhere to configuring ES plugins? As
> this is the first one I've used, I have nothing to compare to...
>
> --
> Hassan Schroeder ------------------------ [hassan.s...@gmail.com](mailto:hassan.s...@gmail.com)\
> [Hassan Schroeder | about.me](http://about.me/hassanschroeder)
> twitter: @hassan
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
---
### Author:  [@Hassan\_Schroeder](https://discuss.elastic.co/u/Hassan_Schroeder)
#### Post date: [October 31, 2013, 3:25pm UTC](https://discuss.elastic.co/t/rest-security-surface-area-and-hardening-elasticsearch-installs/10858/10 "2013-10-31T15:25:46Z")
On Thu, Oct 31, 2013 at 7:56 AM, Hendrik [h.j.saly@googlemail.com](mailto:h.j.saly@googlemail.com) wrote:
> can you please post your elasticsearch.yml config file?
It's just the default from a fresh install of ES 0.90.5, which means
nothing but commented-out examples 🙂
Adding that one line is all I'm doing. But the coffee just kicked in and
I realized what's wrong with your doc -- there's no space between the
'[http.org](http://http.org):' key and the value, so invalid YAML. Adding the space fixed
it (or at least I don't get the error now - will see how the rest of it goes).
## Thanks,
Hassan Schroeder ------------------------ [hassan.schroeder@gmail.com](mailto:hassan.schroeder@gmail.com)
[Hassan Schroeder | about.me](http://about.me/hassanschroeder)
twitter: @hassan
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [July 6, 2017, 2:09am UTC](https://discuss.elastic.co/t/rest-security-surface-area-and-hardening-elasticsearch-installs/10858/11 "2017-07-06T02:09:36Z")