sscarduzio / elasticsearch-readonlyrest-plugin Goto Github PK

Loving this plug, any chance we can get an upgrade for Elasticsearch version 1.3?

Kibana 3.0.0 makes requests to elastic search from within the browser, so I can't find a way to whitelist all the requests made by Kibana using only the tools given by this plugin. I want Kibana to be able to function properly (using POST and GET methods), but still limit access to the rest API in the normal way.

The only way that I've been able to get around this is by whitelisting the IP of my machine, which for use by an entire organization, does not scale well. Is there a way that I could isolate requests from Kibana specifically by request URL? As of right now, I can't find a way.

I wrote some code to do dynamic indices aliasing. The idea is very simple: I get an index (ex: paolo) and I dynamically check for what indices I have access to and I replace 'paolo' with such list (ex: idx1, idx2). I run this code after the current indices filter is executed and I specify in the configuration that only acceptable index is 'paolo'.

When I tried though, I would get blocked. It turns out the indices filter is called twice. The first time (with index 'paolo') would validate. While the second one (with the indices idx1 and idx2) would fail as it does not meet the 'paolo' requirement.

Simone, do you know why the filter is called twice?

Following up from #31 with @nitram4

Less invasive, no-persistence solution (attempt, see if it works)

When the client authenticates via Basic HTTP Auth (without the cookie), we accept the request and set a cookie with no expiration time containing the timestamp of the first login.

Every time the client comes with the authentication in the headers, we check his cookie. If it's too old than the configured value, we delete its cookie and respond 401.

If this does not work for some reason

We'd need server side storage for the sessions. Guava has some in memory cache with time and size based eviction (and there's also some overflow to disk solution around it).
We could also store stuff in our own index, but that's a very heavy handed solution for this task. Maybe for later bigger features may be worth it?

I have successfully installed readonlyrest plugin version 1.7 into an elasticsearch 2.2 instance. I can start elasticsearch and verify that the line 'plugins[readonlyrest]' is contained in the elasticsearch log file.

However, if I start to configure readonlyrest plugin in /etc/elasticsearch/elasticsearch.yml file, elasticsearch does not start and elasticsearch.log file never gets created. Below is my configuration.

readonlyrest:
    enable: true
    access_control_rules:

    - name: Accept only GETs with empty body from other host
      type: allow
      methods: [GET]
      maxBodyLength: 0

What am I doing wrong? Is there a way to get more verbose logging?

Thanks,

Nathan

Trying to limit the access to the indices, i build this config:

    - name: Accept oms user
      type: allow
      methods: [GET,POST,HEAD]
      auth_key: user:pass
      indices: [logstash-*-live-*,.kibana]
      kibana_access: ro

This way, the user will be able to check the live logs, but not the other ones
trying to login it works, but then it start to ask for auth and the log reports that the
index logstash-2016.03.31-live-web in not in the list.

So looks like the indices filter is not applying the wildcards, just doing literal match.
i tried substring - indices: [live,.kibana] - but it also didn't work. Is this a bug or i'm doing it wrongly? What is the correct way to do this?

Thanks!

New "ro+" conf value for kibana_access. This feature will allow read-write requests to the ".kibana" index, still enforcing a read only constraint on requests about other indices.

Add an optional rule kibana_index to specify a kibana index different than the default ".kibana" (ref. custom "kibana.index" configuration in kibana.yml)

Make also sure that we give "rw" access to kibana-devnull when kibana_accessis "rw" or "ro+".

can it be used with kibana 4 and basic http auth ending up with multiple users with multiple ACL accessing thru Kibana 4?
thanks

According to the Elastic documentation, the search API can be used with POST.

What is the best way to allow the search API to be opened to all?

I considered using something like uri_re: .*/_search/.*. Would this make sense?

When I do an (unauthorized) request for http://localhost:9200/_nodes/stats I get the following ClassCastException:

java.lang.ClassCastException: org.elasticsearch.action.admin.indices.stats.CommonStatsFlags cannot be cast to [Ljava.lang.String; at org.elasticsearch.plugin.readonlyrest.acl.RequestContext$1.run(RequestContext.java:63) at org.elasticsearch.plugin.readonlyrest.acl.RequestContext$1.run(RequestContext.java:46) at java.security.AccessController.doPrivileged(Native Method) at org.elasticsearch.plugin.readonlyrest.acl.RequestContext.getIndices(RequestContext.java:45) at org.elasticsearch.plugin.readonlyrest.acl.blocks.rules.impl.KibanaAccessRule.match(KibanaAccessRule.java:107) at org.elasticsearch.plugin.readonlyrest.acl.blocks.Block.check(Block.java:112) at org.elasticsearch.plugin.readonlyrest.acl.ACL.check(ACL.java:46) at org.elasticsearch.plugin.readonlyrest.IndexLevelActionFilter.apply(IndexLevelActionFilter.java:82) at org.elasticsearch.action.support.ActionFilter$Simple.apply(ActionFilter.java:64) at org.elasticsearch.action.support.TransportAction$RequestFilterChain.proceed(TransportAction.java:170) at org.elasticsearch.action.support.TransportAction.execute(TransportAction.java:144) at org.elasticsearch.action.support.TransportAction.execute(TransportAction.java:85) at org.elasticsearch.client.node.NodeClient.doExecute(NodeClient.java:58) at org.elasticsearch.client.support.AbstractClient.execute(AbstractClient.java:359) at org.elasticsearch.client.FilterClient.doExecute(FilterClient.java:52) at org.elasticsearch.rest.BaseRestHandler$HeadersAndContextCopyClient.doExecute(BaseRestHandler.java:83) at org.elasticsearch.client.support.AbstractClient.execute(AbstractClient.java:359) at org.elasticsearch.client.support.AbstractClient$ClusterAdmin.execute(AbstractClient.java:853) at org.elasticsearch.client.support.AbstractClient$ClusterAdmin.nodesStats(AbstractClient.java:948) at org.elasticsearch.rest.action.admin.cluster.node.stats.RestNodesStatsAction.handleRequest(RestNodesStatsAction.java:109) at org.elasticsearch.rest.BaseRestHandler.handleRequest(BaseRestHandler.java:54) at org.elasticsearch.rest.RestController.executeHandler(RestController.java:205) at org.elasticsearch.rest.RestController$RestHandlerFilter.process(RestController.java:279) at org.elasticsearch.rest.RestController$ControllerFilterChain.continueProcessing(RestController.java:260) at org.elasticsearch.plugin.readonlyrest.ReadonlyRestAction$1.process(ReadonlyRestAction.java:39) at org.elasticsearch.rest.RestController$ControllerFilterChain.continueProcessing(RestController.java:263) at org.elasticsearch.rest.RestController.dispatchRequest(RestController.java:176) at org.elasticsearch.http.HttpServer.internalDispatchRequest(HttpServer.java:128) at org.elasticsearch.http.HttpServer$Dispatcher.dispatchRequest(HttpServer.java:86) at org.elasticsearch.http.netty.NettyHttpServerTransport.dispatchRequest(NettyHttpServerTransport.java:449) at org.elasticsearch.http.netty.HttpRequestHandler.messageReceived(HttpRequestHandler.java:61) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) at org.elasticsearch.http.netty.pipelining.HttpPipeliningHandler.messageReceived(HttpPipeliningHandler.java:60) at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) at org.jboss.netty.handler.codec.http.HttpChunkAggregator.messageReceived(HttpChunkAggregator.java:145) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) at org.jboss.netty.handler.codec.http.HttpContentDecoder.messageReceived(HttpContentDecoder.java:108) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296) at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:459) at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:536) at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:435) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) at org.elasticsearch.common.netty.OpenChannelsHandler.handleUpstream(OpenChannelsHandler.java:75) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:108) at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337) at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89) at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)

Following up from #31 with @nitram4:

We'd need to:

1. Install Marvel https://register.elastic.co/marvel_register
2. See what actions the dashboard performs on what indices
3. Obtain the most minimal conf. recipe for RO dashboard access
4. Obtain the most minimal conf. recipe for RW dashboard access

ref. for Kibana we had this official document that laid out the conf for us, didn't find anything similar for Marvel.
https://www.elastic.co/guide/en/shield/shield-1.2/_shield_with_kibana_4.html

ElasticSearch v2.0.0

plugin.bat install file:D:/elasticsearch-readonlyrest-v1.4_es-v2.0.0.zip
-> Installing from file:D:/elasticsearch-readonlyrest-v1.4_es-v2.0.0.zip...
Trying file:D:/elasticsearch-readonlyrest-v1.4_es-v2.0.0.zip ...
Downloading .DONE
Verifying file:D:/elasticsearch-readonlyrest-v1.4_es-v2.0.0.zip checksums if available ...
NOTE: Unable to verify checksum for downloaded plugin (unable to find .sha1 or .md5 file to verify)
ERROR: Could not find plugin descriptor 'plugin-descriptor.properties' in plugin zip

Hello, I have elasticsearch 1.5.2 and I was trying to install elasticsearch-readonlyrest-v1.3_es-v1.5.2
During start elasticsearch service I receive:
[2016-01-28 15:51:07,102][ERROR][bootstrap ] Exception
org.elasticsearch.common.inject.CreationException: Guice creation errors:

1. Error injecting constructor, java.lang.NoSuchMethodError: org.elasticsearch.rest.BaseRestHandler.(Lorg/elasticsearch/common/settings/Settings;Lorg/elasticsearch/client/Client;)V
   at org.elasticsearch.rest.action.readonlyrest.ReadonlyRestAction.(Unknown Source)
   while locating org.elasticsearch.rest.action.readonlyrest.ReadonlyRestAction

1 error
at org.elasticsearch.common.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:344)
at org.elasticsearch.common.inject.InjectorBuilder.injectDynamically(InjectorBuilder.java:178)
at org.elasticsearch.common.inject.InjectorBuilder.build(InjectorBuilder.java:110)

I've tried with java 1.7.76, 1.8.05, 1.8.45 and 1.8.72 - still the same error

Due to the lack of positive results I decided to try version for ES 1.6 - elasticsearch-readonlyrest-v1.4_es-v1.6.0
For a short moment I though that it finally works but in few minutes I relized that it works only for IP but not for subnets. Config is correct because I've tried exactly the same configuration with my test machine with ES 2.1 (java 1.8.51) and on it everything works fine! But I can't upgrade ES on production environment, it must be 1.5.2

In attachments you can see my config in elasticsearch.yml and part of ES log where I can see that ACL config is correctly interpreted. With this config on host 172.18.0.1 I receive 'Sorry, your request is forbidden' but when I change in config [172.18.0.0/24] to [172.18.0.1] then access is possible. As I mentioned - It doesn't work when I try to make configuration for subnets.

How can I force readonlyrest v1.4_es_1.6.0 to work with subnets configuration?
Or maybe there is a way to run elasticsearch-readonlyrest-v1.3_es-v1.5.2 ?

Attachments:
elasticsearch.yml works for ES 2.1 + elasticsearch-readonlyrest-v1.5_es-v2.1.1.zip and works without subnets support for ES 1.5.2 + elasticsearch-readonlyrest-v1.4_es-v1.6.0

elasticsearch.log - it is a start sequence for ES 1.5.2 with readonlyrest v1.4_es_1.6.0

elasticsearch.log.txt
elasticsearch.yml.txt

So, I've been trying to use the plugin and it was working fine, so I decided to put some more limits on my index with the following rule:

- name: Write Access
  type: allow
  uri_re: ^.*\:9200\/indexkatz.*
  api_keys: [readwrite]
  methods: [OPTIONS,GET,POST,PUT]

But when trying to use this index, I receive access denied. If I just remove the line of the 'uri_re' and still use the Api-Key (and the other options) the ACL still working fine (I'm able to index, search but not to delete the index).

Don't know if I'm missing something :)

Thanks!

Repeat tests mentioned in #50 within a cluster and try to reproduce the weird behavior seen in #50 in a multi node environment.

In general, would be good to add test coverage for clustered ES with sharded indices.

I followed the instructions very closely, I disabled the auth on my nginx reverse proxy even....go to access Kibana and brought to that fantastic server status page that reports 'Authentication exception' for Elasticsearch

Hi,

My configuration is :

readonlyrest:
    enable: true
    response_if_req_forbidden: Sorry, your request is forbidden.
    access_control_rules:
    - name:  full access if Basic HTTP auth
      type: allow
      auth_key: "user:password"

And installed from https://github.com/sscarduzio/elasticsearch-readonlyrest-plugin/blob/master/download/elasticsearch-readonlyrest-v1.4_es-v1.7.1.zip?raw=true
And the node won't start with the following stack trace:

[2016-02-09 16:04:24,186][INFO ][node                     ] [es-dev-04] version[1.7.4], pid[3022], build[0d3159b/2015-12-15T11:25:18Z]
[2016-02-09 16:04:24,187][INFO ][node                     ] [es-dev-04] initializing ...
[2016-02-09 16:04:24,241][INFO ][plugins                  ] [es-dev-04] loaded [readonlyrest], sites [head]
[2016-02-09 16:04:24,265][INFO ][env                      ] [es-dev-04] using [1] data paths, mounts [[/ (/dev/vda1)]], net usable_space [44.5gb], net total_space [98.4gb], types [ext4]
[2016-02-09 16:04:25,971][ERROR][rest.action.readonlyrest ] [es-dev-04] impossible to initialize ACL configuration
org.elasticsearch.rest.action.readonlyrest.acl.RuleConfigurationError: insufficient or invalid configuration for rule: 'full access if Basic HTTP auth'
    at org.elasticsearch.rest.action.readonlyrest.acl.Rule.build(Rule.java:90)
    at org.elasticsearch.rest.action.readonlyrest.acl.ACL.readRules(ACL.java:31)
    at org.elasticsearch.rest.action.readonlyrest.acl.ACL.<init>(ACL.java:20)
    at org.elasticsearch.rest.action.readonlyrest.ReadonlyRestAction.<init>(ReadonlyRestAction.java:49)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at org.elasticsearch.common.inject.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:54)
    at org.elasticsearch.common.inject.ConstructorInjector.construct(ConstructorInjector.java:86)
    at org.elasticsearch.common.inject.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:98)
    at org.elasticsearch.common.inject.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:45)
    at org.elasticsearch.common.inject.InjectorImpl.callInContext(InjectorImpl.java:837)
    at org.elasticsearch.common.inject.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:42)
    at org.elasticsearch.common.inject.Scopes$1$1.get(Scopes.java:57)
    at org.elasticsearch.common.inject.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:45)
    at org.elasticsearch.common.inject.InjectorBuilder$1.call(InjectorBuilder.java:200)
    at org.elasticsearch.common.inject.InjectorBuilder$1.call(InjectorBuilder.java:193)
    at org.elasticsearch.common.inject.InjectorImpl.callInContext(InjectorImpl.java:830)
    at org.elasticsearch.common.inject.InjectorBuilder.loadEagerSingletons(InjectorBuilder.java:193)
    at org.elasticsearch.common.inject.InjectorBuilder.injectDynamically(InjectorBuilder.java:175)
    at org.elasticsearch.common.inject.InjectorBuilder.build(InjectorBuilder.java:110)
    at org.elasticsearch.common.inject.Guice.createInjector(Guice.java:93)
    at org.elasticsearch.common.inject.Guice.createInjector(Guice.java:70)
    at org.elasticsearch.common.inject.ModulesBuilder.createInjector(ModulesBuilder.java:59)
    at org.elasticsearch.node.internal.InternalNode.<init>(InternalNode.java:210)
    at org.elasticsearch.node.NodeBuilder.build(NodeBuilder.java:159)
    at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:77)
    at org.elasticsearch.bootstrap.Bootstrap.main(Bootstrap.java:245)
    at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:32)
[2016-02-09 16:04:27,111][ERROR][bootstrap                ] Exception
org.elasticsearch.common.inject.CreationException: Guice creation errors:

1) Error injecting constructor, org.elasticsearch.rest.action.readonlyrest.acl.RuleConfigurationError: insufficient or invalid configuration for rule: 'full access if Basic HTTP auth'
  at org.elasticsearch.rest.action.readonlyrest.ReadonlyRestAction.<init>(Unknown Source)
  while locating org.elasticsearch.rest.action.readonlyrest.ReadonlyRestAction

1 error
    at org.elasticsearch.common.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:344)
    at org.elasticsearch.common.inject.InjectorBuilder.injectDynamically(InjectorBuilder.java:178)
    at org.elasticsearch.common.inject.InjectorBuilder.build(InjectorBuilder.java:110)
    at org.elasticsearch.common.inject.Guice.createInjector(Guice.java:93)
    at org.elasticsearch.common.inject.Guice.createInjector(Guice.java:70)
    at org.elasticsearch.common.inject.ModulesBuilder.createInjector(ModulesBuilder.java:59)
    at org.elasticsearch.node.internal.InternalNode.<init>(InternalNode.java:210)
    at org.elasticsearch.node.NodeBuilder.build(NodeBuilder.java:159)
    at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:77)
    at org.elasticsearch.bootstrap.Bootstrap.main(Bootstrap.java:245)
    at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:32)
Caused by: org.elasticsearch.rest.action.readonlyrest.acl.RuleConfigurationError: insufficient or invalid configuration for rule: 'full access if Basic HTTP auth'
    at org.elasticsearch.rest.action.readonlyrest.acl.Rule.build(Rule.java:90)
    at org.elasticsearch.rest.action.readonlyrest.acl.ACL.readRules(ACL.java:31)
    at org.elasticsearch.rest.action.readonlyrest.acl.ACL.<init>(ACL.java:20)
    at org.elasticsearch.rest.action.readonlyrest.ReadonlyRestAction.<init>(ReadonlyRestAction.java:49)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at org.elasticsearch.common.inject.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:54)
    at org.elasticsearch.common.inject.ConstructorInjector.construct(ConstructorInjector.java:86)
    at org.elasticsearch.common.inject.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:98)
    at org.elasticsearch.common.inject.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:45)
    at org.elasticsearch.common.inject.InjectorImpl.callInContext(InjectorImpl.java:837)
    at org.elasticsearch.common.inject.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:42)
    at org.elasticsearch.common.inject.Scopes$1$1.get(Scopes.java:57)
    at org.elasticsearch.common.inject.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:45)
    at org.elasticsearch.common.inject.InjectorBuilder$1.call(InjectorBuilder.java:200)
    at org.elasticsearch.common.inject.InjectorBuilder$1.call(InjectorBuilder.java:193)
    at org.elasticsearch.common.inject.InjectorImpl.callInContext(InjectorImpl.java:830)
    at org.elasticsearch.common.inject.InjectorBuilder.loadEagerSingletons(InjectorBuilder.java:193)
    at org.elasticsearch.common.inject.InjectorBuilder.injectDynamically(InjectorBuilder.java:175)
    ... 9 more

Nevertheless, with IP filtering it worked like a charm. Is something missing in my configuration? Or is there a bug?

Thanks,

Trying to install in ES 2.2.1 it gives this error:

 /usr/share/elasticsearch/bin/plugin  install https://github.com/sscarduzio/elasticsearch-readonlyrest-plugin/raw/master/download/elasticsearch-readonlyrest-v1.7_es-v2.2.0.zip
-> Installing from https://github.com/sscarduzio/elasticsearch-readonlyrest-plugin/raw/master/download/elasticsearch-readonlyrest-v1.7_es-v2.2.0.zip...
Trying https://github.com/sscarduzio/elasticsearch-readonlyrest-plugin/raw/master/download/elasticsearch-readonlyrest-v1.7_es-v2.2.0.zip ...
Downloading ..DONE
Verifying https://github.com/sscarduzio/elasticsearch-readonlyrest-plugin/raw/master/download/elasticsearch-readonlyrest-v1.7_es-v2.2.0.zip checksums if available ...
NOTE: Unable to verify checksum for downloaded plugin (unable to find .sha1 or .md5 file to verify)
ERROR: Plugin [readonlyrest] is incompatible with Elasticsearch [2.2.1]. Was designed for version [2.2.0]

Please update the zip to run on this version or tell us if there is any hack to do it.
Thanks

Am having some issues getting your version 1.2 plugin working with my ES 1.2

I am partially new to ES so forgive me if it's a stupid error.

Plugin lives in plugins/readonlyrest/readonlyrest-1.3.jar and when I start her up she throws:

{1.2.0}: Initialization Failed ...
1) NullPointerException[null]
org.elasticsearch.common.inject.CreationException: Guice creation errors:

1) Error injecting constructor, java.lang.NullPointerException
  at org.elasticsearch.rest.action.readonlyrest.ReadonlyRestAction.<init>(Unknown Source)
  while locating org.elasticsearch.rest.action.readonlyrest.ReadonlyRestAction

1 error
    at org.elasticsearch.common.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:344)
    at org.elasticsearch.common.inject.InjectorBuilder.injectDynamically(InjectorBuilder.java:178)
    at org.elasticsearch.common.inject.InjectorBuilder.build(InjectorBuilder.java:110)
    at org.elasticsearch.common.inject.Guice.createInjector(Guice.java:93)
    at org.elasticsearch.common.inject.Guice.createInjector(Guice.java:70)
    at org.elasticsearch.common.inject.ModulesBuilder.createInjector(ModulesBuilder.java:59)
    at org.elasticsearch.node.internal.InternalNode.<init>(InternalNode.java:188)
    at org.elasticsearch.node.NodeBuilder.build(NodeBuilder.java:159)
    at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:70)
    at org.elasticsearch.bootstrap.Bootstrap.main(Bootstrap.java:203)
    at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:32)
Caused by: java.lang.NullPointerException
    at org.elasticsearch.rest.action.readonlyrest.ConfigurationHelper.<init>(ConfigurationHelper.java:37)
    at org.elasticsearch.rest.action.readonlyrest.ReadonlyRestAction.<init>(ReadonlyRestAction.java:42)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
    at org.elasticsearch.common.inject.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:54)
    at org.elasticsearch.common.inject.ConstructorInjector.construct(ConstructorInjector.java:86)
    at org.elasticsearch.common.inject.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:98)
    at org.elasticsearch.common.inject.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:45)
    at org.elasticsearch.common.inject.InjectorImpl.callInContext(InjectorImpl.java:837)
    at org.elasticsearch.common.inject.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:42)
    at org.elasticsearch.common.inject.Scopes$1$1.get(Scopes.java:57)
    at org.elasticsearch.common.inject.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:45)
    at org.elasticsearch.common.inject.InjectorBuilder$1.call(InjectorBuilder.java:200)
    at org.elasticsearch.common.inject.InjectorBuilder$1.call(InjectorBuilder.java:193)
    at org.elasticsearch.common.inject.InjectorImpl.callInContext(InjectorImpl.java:830)
    at org.elasticsearch.common.inject.InjectorBuilder.loadEagerSingletons(InjectorBuilder.java:193)
    at org.elasticsearch.common.inject.InjectorBuilder.injectDynamically(InjectorBuilder.java:175)
    ... 9 more

Lastly I pasted in your Full plugin configuration example from your wiki to get it started. If I remove the plugin, Elasticsearch works again.

We are eagerly waiting for the release of ES 2.3.2 because of an issue which is a blocker for us (elastic/elasticsearch#17483).

We also want to use your plugin, and I notice you create a different zip for each version of ES. Is this important? Will the plugin generated for 2.3.1 work with 2.3.2? Or do we need to wait for a new plugin before we can upgrade?

I've been trying to understand the possible values for the actions field in the Supported Rules page and by reviewing the code, both of the plugin and ES.

Is this value specific to the data, as the indices are? Or does it refer to the diferent APIs and actions in the elastic search docs?If it's the latter, it would be great to have a list or something.

In the code I see that it picks it up from the ActionRequest in the RequestContext, but I'm unable to follow what kind of actions are defined in ES.

I'm a bit new around ES, so this might be something I'm missing as a rookie.

Thanks.

I have not been able to install the plugin following the pre built zip instructions. I am getting unknown command url. I tried using
sudo bin/plugin install file:///tmp/elasticsearch-readonlyrest-plugin434172537190131624.zip

but I get:
-> Installing from file:/tmp/elasticsearch-readonlyrest-plugin434172537190131624.zip...
Trying file:/tmp/elasticsearch-readonlyrest-plugin434172537190131624.zip ...
Downloading ...DONE
Verifying file:/tmp/elasticsearch-readonlyrest-plugin434172537190131624.zip checksums if available ...
NOTE: Unable to verify checksum for downloaded plugin (unable to find .sha1 or .md5 file to verify)
ERROR: Could not find plugin descriptor 'plugin-descriptor.properties' in plugin zip

I have just upgraded my elasticsearch install to 2.3.1 thinking innocently that your build for 2.3.0 would work...

I received the following error message:

ERROR: Plugin [readonlyrest] is incompatible with Elasticsearch [2.1.2]. Was designed for version [2.1.1]

Is it possible to override this? or are you able to provide support for Elasticsearch 2.1.2?

Thank you

I'm hitting request matches no rules, forbidden by default when I try to do queries from a web app using elastic.js, which sends POST requests to the ES server.

I'm developing on 127.0.0.1 and the plugin is set up to allow all traffic from this host.

- name: full access to internal servers
type: allow
hosts: [127.0.0.1, localhost]

CURL works fine though. What do I do wrong?

Hello,

I have elasticseach deployed on a VM and used this plugin to secure it. I added the default lines you give to the elasticsearch.yml file and now I can't connect to my elasticsearch service, even from inside the VM.
curl http://127.0.0.1:9200
curl: (7) couldn't connect to host

Am I doing something wrong? Also, how can I allow my local machine IP to connect to the elasticsearch instance on the VM?

thank you in advance

Ability to match by action (a la Shield). Examples of actions:

      "cluster:monitor/nodes/info"
      "cluster:monitor/health"
      "indices:admin/exists"
      "indices:admin/mappings/fields/get"

With this configuration and kibana4:

     - name: kibana_index maintenance
       type: allow
       indices: [.kibana*]
       auth_key: kibana:password

The following appears in the elasticsearch log every few seconds:

[2016-04-22 10:30:19,427][WARN ][plugin.readonlyrest.acl  ] Failed to discover indices associated to this request: org.elasticsearch.plugin.readonlyrest.acl.RequestContext$1@455eca37
[2016-04-22 10:30:21,933][WARN ][plugin.readonlyrest.acl  ] Failed to discover indices associated to this request: org.elasticsearch.plugin.readonlyrest.acl.RequestContext$1@49da2199
[2016-04-22 10:30:24,439][WARN ][plugin.readonlyrest.acl  ] Failed to discover indices associated to this request: org.elasticsearch.plugin.readonlyrest.acl.RequestContext$1@30aeccb1

Note the user kibana is the elasticsearch user configured in the kibana.yml for kibana_index maintenance. Looking closer it looks like it's the request for /_nodes (which is being denied) that is causing this warning.

Adding the following ACL makes requests for /_nodes work, and also stops the warning:

    - name: kibana maintenance
      type: allow
      actions: ['cluster:*']
      auth_key: kibana:password

Carrying over from a discussion in #11 with @ivukotic

Hi,

What marvel is trying to do is this:

curl -XPOST http://cl-analytics.mwt2.org:9200/.marvel-2015.11.10/_search -d '{"facets":{"query":{"terms":{"field":"node.name","size":100},"facet_filter":{"fquery":{"query":{"filtered":{"query":{"query_string":{"query":"_type:node_stats"}},"filter":{"bool":{"must":[{"range":{"@timestamp":{"from":1447119335396,"to":1447122935396}}}]}}}}}}}},"size":0}’

so I made what you suggested:
uri_re: ^http://._.marvel.__search.*

but the access is still not possible. Does it have to be on all the machines or only on the master node?

Thanks,
Ilija

Hi Simone,

I've downloaded your read-only rest plugin for elasticsearch.
Good that finally someone implemented so awesome thing. Good job!

Is it possible to set up your plugin as following:

• Anonymous users will have only read-only access, they cannot save/modify anything. However they can search for data (Discover tab in Kibana), they can open dashboards as well in read only mode.
• Other users who provide Login & Password, will have save/modify permissions as well.

Thanks in advance.

Is it possible to have acl based ofn a field value? the classic example if you have a field called "env" and all docs are in the same index, you could then limit access to specific data, env:prod, env:test, env:dev.

This could either be done by modifying the request before it reaches ES or by stripping out documents before they leave ES.

Simone, I am not sure that is of interest, but I have a version of the latest code base working with ES v.1.4.4. Something I had to do for some internal reasons.

If that is of interest I can share it as well. I am not sure would be that helpful for anybody though.

Hi Simone ,

Thank you so much for readonly rest plugin . Really helpful for my application .

But somehow I’m facing issue to make it work with Kibana3 . Is your plugin work for OPTIONS method ? Looks like kibana3 sending OPTIONS/POST method and page failing with Invalid HTTP status code 403 .
I think “whitelist” do only validate client-ip , is it possible to validate server-ip too ? Because that would help bypass kibana server request from readonly validation .

Thanks,
Sankar.

The original pull request (https://github.com/sscarduzio/elasticsearch-readonlyrest-plugin/pull/9/files#diff-1903ac875e0e210c93a416feb366b81bR91) does not conform to HTTP basic auth.

Ref: https://en.wikipedia.org/wiki/Basic_access_authentication

Hi,

Is there a way to allow read/write access to a specific type of an index ?
For example, if I have a type posts and comments inside a ES index.
I would like to unauthorized write access to posts (only readonly) and allow to customer to add comment on the type comments ( I would like to use update, bulk api, insert).

Best regards,

Elastic Search 1.5.x elasticsearch-readonlyrest-v1.3_es-v1.5.*.zip
unbuntu 14.04 and java version "1.8.0_66"

I've got the following error

1) Error injecting constructor, java.lang.NoSuchMethodError: org.elasticsearch.rest.BaseRestHandler.<init>(Lorg/elasticsearch/common/settings/Settings;Lorg/elasticsearch/client/Client;)V
  at org.elasticsearch.rest.action.readonlyrest.ReadonlyRestAction.<init>(Unknown Source)
  while locating org.elasticsearch.rest.action.readonlyrest.ReadonlyRestAction

1 error
    at org.elasticsearch.common.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:344)
    at org.elasticsearch.common.inject.InjectorBuilder.injectDynamically(InjectorBuilder.java:178)
    at org.elasticsearch.common.inject.InjectorBuilder.build(InjectorBuilder.java:110)
    at org.elasticsearch.common.inject.Guice.createInjector(Guice.java:93)
    at org.elasticsearch.common.inject.Guice.createInjector(Guice.java:70)
    at org.elasticsearch.common.inject.ModulesBuilder.createInjector(ModulesBuilder.java:59)
    at org.elasticsearch.node.internal.InternalNode.<init>(InternalNode.java:203)
    at org.elasticsearch.node.NodeBuilder.build(NodeBuilder.java:159)
    at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:70)
    at org.elasticsearch.bootstrap.Bootstrap.main(Bootstrap.java:213)
    at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:32)
Caused by: java.lang.NoSuchMethodError: org.elasticsearch.rest.BaseRestHandler.<init>(Lorg/elasticsearch/common/settings/Settings;Lorg/elasticsearch/client/Client;)V
    at org.elasticsearch.rest.action.readonlyrest.ReadonlyRestAction.<init>(ReadonlyRestAction.java:41)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
    at org.elasticsearch.common.inject.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:54)
    at org.elasticsearch.common.inject.ConstructorInjector.construct(ConstructorInjector.java:86)
    at org.elasticsearch.common.inject.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:98)
    at org.elasticsearch.common.inject.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:45)
    at org.elasticsearch.common.inject.InjectorImpl.callInContext(InjectorImpl.java:837)
    at org.elasticsearch.common.inject.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:42)
    at org.elasticsearch.common.inject.Scopes$1$1.get(Scopes.java:57)
    at org.elasticsearch.common.inject.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:45)
    at org.elasticsearch.common.inject.InjectorBuilder$1.call(InjectorBuilder.java:200)
    at org.elasticsearch.common.inject.InjectorBuilder$1.call(InjectorBuilder.java:193)
    at org.elasticsearch.common.inject.InjectorImpl.callInContext(InjectorImpl.java:830)
    at org.elasticsearch.common.inject.InjectorBuilder.loadEagerSingletons(InjectorBuilder.java:193)
    at org.elasticsearch.common.inject.InjectorBuilder.injectDynamically(InjectorBuilder.java:175)
    ... 9 more

Following up from #31 with @nitram4

There could be the possibility to mimic the Shield REST API for login/logout. Shield's Kibana plugin is free to install and source is not uglified, so that's encouraging.

The most delicate part is to mock the original Shield API paths, worth investigating because we could have a proper login form rather than basic auth's browser modal window in Kibana.

Just installed v1.9.1 with ES 2.3.1, and plugged Use Case #2 into elasticsearch.yml. ES started OK, but starting the Kibana server showed:
~/kibana$ bin/kibana
log [09:44:26.639] [info][status][plugin:kibana] Status changed from uninitialized to green - Ready
log [09:44:26.689] [info][status][plugin:elasticsearch] Status changed from uninitialized to yellow - Waiting for Elasticsearch
log [09:44:26.715] [info][status][plugin:kbn_vislib_vis_types] Status changed from uninitialized to green - Ready
log [09:44:26.724] [info][status][plugin:markdown_vis] Status changed from uninitialized to green - Ready
log [09:44:26.729] [info][status][plugin:metric_vis] Status changed from uninitialized to green - Ready
log [09:44:26.736] [info][status][plugin:spyModes] Status changed from uninitialized to green - Ready
log [09:44:26.754] [info][status][plugin:statusPage] Status changed from uninitialized to green - Ready
log [09:44:26.760] [info][status][plugin:table_vis] Status changed from uninitialized to green - Ready
log [09:44:26.783] [info][listening] Server running at http://0.0.0.0:5601
log [09:44:26.792] [error][status][plugin:elasticsearch] Status changed from yellow to red - Authentication Exception

Trying to start Kibana from the browser showed a RED - authentication error message. I restarted ES, and it became unresponsive. Any request to :9200 waited forever. Removing the plugin broke ES and Kibana to the point they had to be reloaded.

If I can provide any additional debugging info, please let me know. This might be user error, but I thought I'd let you know...

Hi,
I'm trying your plugin to add a layer of security into ES and divide each user to see his own data via kibana dashboard.
I installed the plugin and worked fine with the use case 2 configuration(kibana) then i wanted to restrict the single users with indices permissions so i used this configuration to test as admin user:

readonlyrest:
    enable: true
    response_if_req_forbidden: Sorry, your request is forbidden.
    access_control_rules:

    - name: Just certain indices, and read only
      type: allow 
      indices: [logstash*,.kibana*] 
      kibana_access: rw
      auth_key: admin:passwd3

But it doesn't work, and on kibana dashboard i get plugin:elasticsearch Authentication Exception in the status page even if on the kibana .yml configuration i added :

 elasticsearch.username: admin
 elasticsearch.password: passwd3

And on logstash(with authentication):
message=>"[401] Sorry, your request is forbidden."

Another "bug" i found is that using your use case 1 configuration won't start on ES unless you comment\delete this line:
actions: [cluster:*, indices:data/read/*]

My ACL configuration should be something like this:
User has permission to read/write only on his data(logstash-user-* and kibana)
Admin has permission everywhere

ES version: 2.3.1
Plugin: 1.9.1 for 2.3.1

Thanks for the plugin. I am facing an issue with basic authentication
I wrote the access control rule to have basic authentication in elasticseach configuration.
Basic Authorisation key (clients should send this key base64-encoded in the 'Auth' header)
> - name: full access if Basic HTTP auth
> type: allow
> auth_key: random_password
auth_key is in plain text

Now when I try to access the elasticsearch url without authentication it gives a null pointer exception ,that is good.

But I could access my elasticsearch with any random basic authentication header (even if doesn't match auth_key) when i hit the url.
Please help to resolve soon

Trying to use the kopf plugin to check a 2 nodes ES setup, i get this:

Mar 28 21:17:48 ES1 elasticsearch[26307]: [2016-03-28 21:17:48,578][INFO ][rest.suppressed          ] /_nodes/stats/jvm,fs,os,process Params: {metric=jvm,fs,os,process}
Mar 28 21:17:48 ES1 elasticsearch[26307]: java.lang.ClassCastException: org.elasticsearch.action.admin.indices.stats.CommonStatsFlags cannot be cast to [Ljava.lang.String;
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.plugin.readonlyrest.acl.blocks.rules.impl.IndicesRule$1.run(IndicesRule.java:55)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.plugin.readonlyrest.acl.blocks.rules.impl.IndicesRule$1.run(IndicesRule.java:48)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at java.security.AccessController.doPrivileged(Native Method)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.plugin.readonlyrest.acl.blocks.rules.impl.IndicesRule.getIndices(IndicesRule.java:47)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.plugin.readonlyrest.acl.blocks.rules.impl.IndicesRule.match(IndicesRule.java:73)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.plugin.readonlyrest.acl.blocks.Block.check(Block.java:104)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.plugin.readonlyrest.acl.ACL.check(ACL.java:46)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.plugin.readonlyrest.IndexLevelActionFilter.apply(IndexLevelActionFilter.java:82)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.action.support.ActionFilter$Simple.apply(ActionFilter.java:63)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.action.support.TransportAction$RequestFilterChain.proceed(TransportAction.java:99)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.action.support.TransportAction.execute(TransportAction.java:77)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.client.node.NodeClient.doExecute(NodeClient.java:58)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.client.support.AbstractClient.execute(AbstractClient.java:351)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.client.FilterClient.doExecute(FilterClient.java:52)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.rest.BaseRestHandler$HeadersAndContextCopyClient.doExecute(BaseRestHandler.java:83)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.client.support.AbstractClient.execute(AbstractClient.java:351)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.client.support.AbstractClient$ClusterAdmin.execute(AbstractClient.java:845)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.client.support.AbstractClient$ClusterAdmin.nodesStats(AbstractClient.java:940)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.rest.action.admin.cluster.node.stats.RestNodesStatsAction.handleRequest(RestNodesStatsAction.java:109)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.rest.BaseRestHandler.handleRequest(BaseRestHandler.java:54)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.rest.RestController.executeHandler(RestController.java:207)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.rest.RestController$RestHandlerFilter.process(RestController.java:281)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.rest.RestController$ControllerFilterChain.continueProcessing(RestController.java:262)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.plugin.readonlyrest.ReadonlyRestAction$1.process(ReadonlyRestAction.java:39)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.rest.RestController$ControllerFilterChain.continueProcessing(RestController.java:265)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.rest.RestController.dispatchRequest(RestController.java:176)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.http.HttpServer.internalDispatchRequest(HttpServer.java:128)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.http.HttpServer$Dispatcher.dispatchRequest(HttpServer.java:86)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.http.netty.NettyHttpServerTransport.dispatchRequest(NettyHttpServerTransport.java:385)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.http.netty.HttpRequestHandler.messageReceived(HttpRequestHandler.java:63)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.http.netty.pipelining.HttpPipeliningHandler.messageReceived(HttpPipeliningHandler.java:60)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.handler.codec.http.HttpChunkAggregator.messageReceived(HttpChunkAggregator.java:145)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.handler.codec.http.HttpContentDecoder.messageReceived(HttpContentDecoder.java:108)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:459)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:536)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:435)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.elasticsearch.common.netty.OpenChannelsHandler.handleUpstream(OpenChannelsHandler.java:75)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:108)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
Mar 28 21:17:48 ES1 elasticsearch[26307]: at java.lang.Thread.run(Thread.java:745)

Trying other plugins like the "Elastic HQ" also gave problems.
the request that fails is http://192.168.0.1:9200/_nodes/stats/jvm,fs,os,process

Other requests like http://192.168.0.1:9200/_cluster/state/master_node,routing_table,blocks/ and http://192.168.0.1:9200/_nodes/_all/os,jvm do work fine

Before installing the plugin, those "cluster status plugins" did work without any problem.

Thanks

Hi, I want to combine the rules to feed my following need:

only the request from local ip and with x-api-key set in header can be allowed.

Thanks.

I have built readonlyrest-plugin for ES 1.6.0 according to readme instructions and installed it correctly.
However it seems ACL rules are not interpreted correctly.

My config :

readonlyrest:
     # (De)activate plugin
     enable: true

     # HTTP response body in case of forbidden request.
     # If this is null or omitted, the name of the first violated access control rule is returned (useful for debugging!)
     response_if_req_forbidden: Sorry, your request is forbidden

     # Default policy is to forbid everything, let's define a whitelist
     access_control_rules:

     - name: restricted access to all other hosts
     type: allow
     methods: [OPTIONS,GET]
     maxBodyLength: 0

While testing I got :

root@kibana:/tmp/elasticsearch-readonlyrest-plugin# curl 'localhost:9200/_cat/nodes?v' -v -XGET
* Hostname was NOT found in DNS cache
*   Trying ::1...
* Connected to localhost (::1) port 9200 (#0)
> GET /_cat/nodes?v HTTP/1.1
> User-Agent: curl/7.38.0
> Host: localhost:9200
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< Content-Type: application/json; charset=UTF-8
< Content-Length: 51
<
* Connection #0 to host localhost left intact
{"error":"NullPointerException[null]","status":500}

Hi,

First of all, thnx for this module, kinda cool!

So is there anyway to have a login popup for basic auth? So clou can (for example) access kibana with authentication from a browser.

In my syslog i'm receiving a lot of events like this:
Apr 1 14:40:16 ES1 elasticsearch[14690]: KIBANA ACCESS DENIED {action: indices:data/write/bulk[s] OA:/192.168.0.10:42842 M: POST
Apr 1 14:40:16 ES1 elasticsearch[14690]: KIBANA ACCESS DENIED {action: indices:data/write/bulk[s] OA:/192.168.0.10:42842 M: POST
Apr 1 14:40:16 ES1 elasticsearch[14690]: KIBANA ACCESS DENIED {action: indices:data/write/bulk[s] OA:/192.168.0.10:42842 M: POST

i assume that are the topbeat causing this, but they have their own auth and config to be accepted... so i don't understand where this is coming, nor how to fix this (or reduce this event to DEBUG if not important). I'm currently logging INFO in the ES.

I have an ES instance behind nginx, as a TLS proxy, but ES with plugin still sees everything as coming from localhost, even with accept_x-forwarded-for_header: true and proxy passing the header;

# Forward all requests to the local ES instance
location / {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass http://127.0.0.1:9200/;
}

Plugin is active, and if I set auth_key the request is rejected, so the plugin does work.

Is there something that I am missing? A way to debug what the plugin actually sees, in terms of headers? ES 2.2.1 with current master of the plugin.

If you are blocking get/post requests with a body, how can one accomplish anything with Elasticsearch? This would seem to prevent using the Query DSL at all, or am I missing something? Am I supposed to convert a 30-line json query with several levels of nested relations, etc. into a simple URL query string somehow?

Basically what I want to be able to do is say that if a request comes in on the public IP address, it should be readonly, whatever the request is, and on internal IPs, allow to specify a username/password for write access. It seems like this is not currently possible with this addon.

Just tested this with 1.0.1 and everything blew up. Rolled back to 0.90.9 and everything is good again. Any chance support for that is in the works? Or am I missing an easy way to get ROR 1.3 to support ES 1.0.1?

Write a series of wiki pages to show off various use cases, their description and their solution.
Link the recipes in the main README.md (which needs to be much smaller).