REST Security Surface Area and Hardening ElasticSearch Installs

Elastic Stack Elasticsearch
1

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.
For more options, visit https://groups.google.com/groups/opt_out.

2

-----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-jetty1 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/

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.
For more options, visit https://groups.google.com/groups/opt_out.

3

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.
For more options, visit https://groups.google.com/groups/opt_out.

4

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

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.
To unsubscribe from this group and all its topics, send an email to
elasticsearch+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Let's Meet: http://meetme.so/DarrenRush http://meetme.so/DarrenRush
Find me online: Twitter http://twitter.com/darrenrush |
Bloghttp://darrenrush.com|
LinkedIn 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.
For more options, visit https://groups.google.com/groups/opt_out.

5

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<javascript:>

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)

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.
To unsubscribe from this group and all its topics, send an email to
elasticsearc...@googlegroups.com <javascript:>.

For more options, visit https://groups.google.com/groups/opt_out.

--
Let's Meet: http://meetme.so/DarrenRush http://meetme.so/DarrenRush
Find me online: Twitter http://twitter.com/darrenrush | Bloghttp://darrenrush.com|
LinkedIn 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.
For more options, visit https://groups.google.com/groups/opt_out.

6

On Wed, Oct 30, 2013 at 7:56 AM, Hendrik h.j.saly@googlemail.com wrote:

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

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
Hassan Schroeder | about.me
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.
For more options, visit https://groups.google.com/groups/opt_out.

7

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)

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<javascript:>>
wrote:

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

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

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<javascript:>
Hassan Schroeder | about.me
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.
For more options, visit https://groups.google.com/groups/opt_out.

8

On Thu, Oct 31, 2013 at 2:14 AM, Hendrik 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)

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
Hassan Schroeder | about.me
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.
For more options, visit https://groups.google.com/groups/opt_out.

9

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<javascript:>>
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)

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<javascript:>
Hassan Schroeder | about.me
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.
For more options, visit https://groups.google.com/groups/opt_out.

10

On Thu, Oct 31, 2013 at 7:56 AM, Hendrik 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 :slight_smile:

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:' 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
Hassan Schroeder | about.me
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.
For more options, visit https://groups.google.com/groups/opt_out.