I think we should move this to a new thread as it is probably a different
issue. May I suggest moving this to our new discussion forum with a section
specifically for Shield https://discuss.elastic.co/c/shield if you have any
followups to my response below?
To get you some help and on your way though, we do have documentation about
limitations  and node clients.
Also a few other notes, what you've defined for the anonymous user is
actually a different user than the actual system user, so it will not have
the affect you are looking for but instead will give every request without
any user full access. This may be a little confusing but we don't give our
internal system calls full rights, so what you're most probably doing in
your application is checking for the existence of an index somewhere
without specifying any credentials for the request. The details on
specifying credentials per request are located in  as well. The second
note, is have you considered switching to a transport client? With Shield
and node clients embedded in your application, you are essentially making
your application part of the cluster since it is a node and these nodes
need access to all of the Shield files such as users, roles, and the system
On Thursday, May 21, 2015 at 7:12:07 AM UTC-4, Steve Barnes wrote:
I am having a similar issue using ES 1.4.3 + Shield 1.1. As soon as my
application instance (with embedded ES node.client) starts up, it throws :
Caused by: org.elasticsearch.shield.authz.AuthorizationException: action
[indices:admin/exists] is unauthorized for user [__es_system_user]
and therefore my application will not start. I have tried the following as
per the documentation here (
shield.authc: anonymous: roles: admin
shield.authc: anonymous: username:
__es_system_user roles: admin
but they don't have any affect.
If there is any documentation I can read of the restriction(s) in
ES/Shield, please can you point me to it ? I need to understand if this is
something we can program/config around or whether we can patch Shield 1.1
(we only support v1.1 until next release of our application).
On Wednesday, 22 April 2015 13:34:07 UTC+1, Jay Modi wrote:
Thank you for the detailed report and reproduction of this issue. This is
a known limitation with Shield and certain operations in elasticsearch.
We're working to resolve this in a future release.
We will be documenting this limitation and all of the operations affected
shortly; this was something that we had forgotten to document.
On Monday, April 20, 2015 at 10:46:40 AM UTC-4, Bert Vermeiren wrote:
- ElasticSearch 1.5.1
- SHIELD 1.2
Whenever I use a terms lookup filter in a search query, I get an
UnAuthorizedException for the [__es_system_user] user although the actual
user has even 'admin' role privileges.
This seems a bug to me, where the terms filter does not have the correct
This is very easy to reproduce, see gist :
Add user 'admin' with default 'admin' role.
./bin/shield/esusers useradd admin -p admin1 -r admin
curl -XPUT 'admin:admin1@localhost:9200/customer'
create a document on the index
curl -XPUT 'admin:admin1@localhost:9200/customer/external/1' -d '
"name" : "John Doe",
"token" : "token1"
create additional index for the "terms lookup" filter functionality
curl -XPUT 'admin:admin1@localhost:9200/tokens'
create document in 'tokens' index
curl -XPUT 'admin:admin1@localhost:9200/tokens/tokens/1' -d '
"group" : "1",
"tokens" : ["token1", "token2" ]
search with a terms lookup filter on the "customer" index, referring
to the 'tokens' index.
curl -XGET 'admin:admin1@localhost:9200/customer/external/_search' -d '
=> org.elasticsearch.shield.authz.AuthorizationException: action
[indices:data/read/get] is unauthorized for user [__es_system_user]
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 email@example.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/408cb544-1f07-426a-8d23-f6308f33211d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.