For a performance oriented choice, I am working on securing a cluster of ElasticSearch nodes without SSL node-to-node encryption.
I experienced a weird behaviour and I’m are not sure it is intended.
- A node without search-guard can join a cluster secured by search-guard.
- Users can read data from that node.
- Users cannot write data to that node
Is this behaviour intended ? When shards reallocation are triggered, does that mean that shards will be moved to this “rogue” node or the allocation will be only on authenticated nodes with correct searchguard_node.key ?
Thank you and have a great day !
I’ve made some tests, here’s some more info I’ve gathered. I’m following Elastic’ guidelines for an efficient cluster with a Loadbalancer ↔ Master ↔ Worker nodes architecture.
I have enabled search-guard on the master and the worker nodes. On the Loadbalancer I disabled it intentionally.
Now users can query data from my nodes and write too. Obsiously, unauthenticated users can access data but they can write too.
I’m using mock data from accounts.json posted by Elastic:
Here’s the curl for put:
curl -XPUT ‘http://localhost:9200/bank/accounts/1000’ -d ‘{
“account_number”: 995,
“balance”: 21153,
“firstname”: “Phelps”,
“lastname”: “Parrish”,
“age”: 25,
“gender”: “M”,
“address”: “666 Miller Place”,
“employer”: “Pearlessa”,
“email”: “phelpsparrish@pearlessa.com”,
“city”: “Brecon”,
“state”: “AZ”
}’ -
PUT /bank/accounts/1000 HTTP/1.1
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.2.3 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Accept: /
Content-Length: 266
Content-Type: application/x-www-form-urlencoded
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=UTF-8
< Content-Length: 76
<
Here’s the curl for get:
curl -XGET ‘http://localhost:9200/bank/orange/995?pretty’ -v
GET /bank/accounts/995?pretty HTTP/1.1
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.2.3 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Accept: /
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=UTF-8
< Content-Length: 335
<
{
“_index” : “bank”,
“_type” : “accounts”,
“_id” : “995”,
“_version” : 3,
“found” : true,
“_source”:{“account_number”:
995,“balance”:21153,“firstname”:“Phelps”,“lastname”:“Parrish”,“age”:25,“gender”:“M”,“address”:“666 Miller Place",“employer”:“Pearlessa”,“email”:"phelpsparrish@pearlessa.com”,“city”:“Brecon”,“state”:“ME”}
}
Is
there any configuration that I have to change to be able to stop unauthenticated requests interacting with search-guard enabled nodes ?
Thanks for your awesome work, have a great day
Thats an interesting topic cause the original idea was to secure it via ssl. If you have no ssl configued for inter-node communication its curently possible for a node to join the cluster but then, once joined, the permissions for every user are evaluated. we are a little bit unsure which direction to go: 1) make internode ssl more or less mandatory or 2) secure the cluster also without ssl against foreign nodes. But solution 2) will still need some crypto stuff which will decrease performance. Is internode ssl for you really a performance killer? have you do some measurements here?
···
Am 26.06.2015 um 15:30 schrieb simon.minery@gmail.com:
I've made some tests, here's some more info I've gathered. I'm following Elastic' guidelines for an efficient cluster with a Loadbalancer <-> Master <-> Worker nodes architecture.
I have enabled search-guard on the master and the worker nodes. On the Loadbalancer I disabled it intentionally.
Now users can query data from my nodes and write too. Obsiously, unauthenticated users can access data but they can write too.
I'm using mock data from accounts.json posted by Elastic:
Here's the curl for put:
curl -XPUT 'http://localhost:9200/bank/accounts/1000' -d '{
"account_number": 995,
"balance": 21153,
"firstname": "Phelps",
"lastname": "Parrish",
"age": 25,
"gender": "M",
"address": "666 Miller Place",
"employer": "Pearlessa",
"email": "phelpsparrish@pearlessa.com",
"city": "Brecon",
"state": "AZ"
}' -
> PUT /bank/accounts/1000 HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.2.3 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Accept: */*
> Content-Length: 266
> Content-Type: application/x-www-form-urlencoded
>
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=UTF-8
< Content-Length: 76
<
* Closing connection #0
Here's the curl for get:
curl -XGET 'http://localhost:9200/bank/orange/995?pretty' -v
> GET /bank/accounts/995?pretty HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.2.3 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=UTF-8
< Content-Length: 335
<
{
"_index" : "bank",
"_type" : "accounts",
"_id" : "995",
"_version" : 3,
"found" : true,
"_source":{"account_number":
995,"balance":21153,"firstname":"Phelps","lastname":"Parrish","age":25,"gender":"M","address":"666 Miller Place","employer":"Pearlessa","email":"phelpsparrish@pearlessa.com","city":"Brecon","state":"ME"}
}
Is there any configuration that I have to change to be able to stop unauthenticated requests interacting with search-guard enabled nodes ?
Thanks for your awesome work, have a great day
--
You received this message because you are subscribed to the Google Groups "Search Guard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com.
To post to this group, send email to search-guard@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/ad569383-78ee-403a-92b5-2458f780c2ef%40googlegroups.com\.
For more options, visit https://groups.google.com/d/optout\.
Hi,
Do you consider using SASL/Kerberos for inter nodes authentication ?
Regarding the other products like YARN, HDFS, Zookeeper, Hbase … It seems to be the commonest solution.
Regards,
Alexandre
···
On Sunday, June 28, 2015 at 4:20:28 PM UTC+2, SG wrote:
Thats an interesting topic cause the original idea was to secure it via ssl. If you have no ssl configued for inter-node communication its curently possible for a node to join the cluster but then, once joined, the permissions for every user are evaluated. we are a little bit unsure which direction to go: 1) make internode ssl more or less mandatory or 2) secure the cluster also without ssl against foreign nodes. But solution 2) will still need some crypto stuff which will decrease performance. Is internode ssl for you really a performance killer? have you do some measurements here?
Am 26.06.2015 um 15:30 schrieb simon....@gmail.com:
I’ve made some tests, here’s some more info I’ve gathered. I’m following Elastic’ guidelines for an efficient cluster with a Loadbalancer ↔ Master ↔ Worker nodes architecture.
I have enabled search-guard on the master and the worker nodes. On the Loadbalancer I disabled it intentionally.
Now users can query data from my nodes and write too. Obsiously, unauthenticated users can access data but they can write too.
I’m using mock data from accounts.json posted by Elastic:
Here’s the curl for put:
curl -XPUT ‘http://localhost:9200/bank/accounts/1000’ -d '{
“account_number”: 995,
“balance”: 21153,
“firstname”: “Phelps”,
“lastname”: “Parrish”,
“age”: 25,
“gender”: “M”,
“address”: “666 Miller Place”,
“employer”: “Pearlessa”,
“email”: “phelps...@pearlessa.com”,
“city”: “Brecon”,
“state”: “AZ”
}’ -
PUT /bank/accounts/1000 HTTP/1.1
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.2.3 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Accept: /
Content-Length: 266
Content-Type: application/x-www-form-urlencoded
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=UTF-8
< Content-Length: 76
<
Here’s the curl for get:
curl -XGET ‘http://localhost:9200/bank/orange/995?pretty’ -v
GET /bank/accounts/995?pretty HTTP/1.1
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.2.3 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Accept: /
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=UTF-8
< Content-Length: 335
<
{
“_index” : “bank”,
“_type” : “accounts”,
“_id” : “995”,
“_version” : 3,
“found” : true,
“_source”:{“account_number”:
995,“balance”:21153,“firstname”:“Phelps”,“lastname”:“Parrish”,“age”:25,“gender”:“M”,“address”:“666 Miller Place",“employer”:“Pearlessa”,“email”:"phelps...@pearlessa.com”,“city”:“Brecon”,“state”:“ME”}
}
Is there any configuration that I have to change to be able to stop unauthenticated requests interacting with search-guard enabled nodes ?
Thanks for your awesome work, have a great day
–
You received this message because you are subscribed to the Google Groups “Search Guard” group.
To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.
To post to this group, send email to search...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/ad569383-78ee-403a-92b5-2458f780c2ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hi,
Do you consider using SASL/Kerberos for inter nodes authentication ?
yes, but will not be ready soon
···
Am 29.06.2015 um 13:48 schrieb Alexandre LINTE <alex.linte@gmail.com>:
Regarding the other products like YARN, HDFS, Zookeeper, Hbase ... It seems to be the commonest solution.
Regards,
Alexandre
On Sunday, June 28, 2015 at 4:20:28 PM UTC+2, SG wrote:
Thats an interesting topic cause the original idea was to secure it via ssl. If you have no ssl configued for inter-node communication its curently possible for a node to join the cluster but then, once joined, the permissions for every user are evaluated. we are a little bit unsure which direction to go: 1) make internode ssl more or less mandatory or 2) secure the cluster also without ssl against foreign nodes. But solution 2) will still need some crypto stuff which will decrease performance. Is internode ssl for you really a performance killer? have you do some measurements here?
> Am 26.06.2015 um 15:30 schrieb simon....@gmail.com:
>
>
>
>
>
>
> I've made some tests, here's some more info I've gathered. I'm following Elastic' guidelines for an efficient cluster with a Loadbalancer <-> Master <-> Worker nodes architecture.
> I have enabled search-guard on the master and the worker nodes. On the Loadbalancer I disabled it intentionally.
> Now users can query data from my nodes and write too. Obsiously, unauthenticated users can access data but they can write too.
> I'm using mock data from accounts.json posted by Elastic:
>
> Here's the curl for put:
> curl -XPUT 'http://localhost:9200/bank/accounts/1000' -d '{
> "account_number": 995,
> "balance": 21153,
> "firstname": "Phelps",
> "lastname": "Parrish",
> "age": 25,
> "gender": "M",
> "address": "666 Miller Place",
> "employer": "Pearlessa",
> "email": "phelps...@pearlessa.com",
> "city": "Brecon",
> "state": "AZ"
> }' -
> > PUT /bank/accounts/1000 HTTP/1.1
> > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.2.3 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> > Accept: */*
> > Content-Length: 266
> > Content-Type: application/x-www-form-urlencoded
> >
> < HTTP/1.1 200 OK
> < Content-Type: application/json; charset=UTF-8
> < Content-Length: 76
> <
> * Closing connection #0
>
> Here's the curl for get:
> curl -XGET 'http://localhost:9200/bank/orange/995?pretty' -v
> > GET /bank/accounts/995?pretty HTTP/1.1
> > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.2.3 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Content-Type: application/json; charset=UTF-8
> < Content-Length: 335
> <
> {
> "_index" : "bank",
> "_type" : "accounts",
> "_id" : "995",
> "_version" : 3,
> "found" : true,
> "_source":{"account_number":
> 995,"balance":21153,"firstname":"Phelps","lastname":"Parrish","age":25,"gender":"M","address":"666 Miller Place","employer":"Pearlessa","email":"phelps...@pearlessa.com","city":"Brecon","state":"ME"}
> }
>
> Is there any configuration that I have to change to be able to stop unauthenticated requests interacting with search-guard enabled nodes ?
> Thanks for your awesome work, have a great day
>
> --
> You received this message because you are subscribed to the Google Groups "Search Guard" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.
> To post to this group, send email to search...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/ad569383-78ee-403a-92b5-2458f780c2ef%40googlegroups.com\.
> For more options, visit https://groups.google.com/d/optout\.
--
You received this message because you are subscribed to the Google Groups "Search Guard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com.
To post to this group, send email to search-guard@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/4ae856ad-5f5e-4de7-80e6-9541d935799f%40googlegroups.com\.
For more options, visit https://groups.google.com/d/optout\.
Hello again,
I’m working on testing SSL to gather performance stats on searchguard. I’ve enabled searchguard.ssl.transport.node.enabled on my cluster and as predicted I cannot restart the nodes as the index searchguard/ac/ac is unavailable.
^[[2015-06-30 14:03:49,322][ERROR][com.floragunn.searchguard.service.SearchGuardConfigService] [worker-node] Try to refresh security configuration but it failed due to org.elasticsearch.action.NoShardAvailableActionException: [searchguard][4] null
org.elasticsearch.action.NoShardAvailableActionException: [searchguard][4] null
What should I do to ensure than I can restart from a “cold restart” when all the nodes are unavailable ?
Thank you and have a great day.
Pls. do not mix issues within one mail thread. For you problem described below pls. add a new github issue. thanks.
···
Am 30.06.2015 um 14:05 schrieb simon.minery@gmail.com:
Hello again,
I'm working on testing SSL to gather performance stats on searchguard. I've enabled searchguard.ssl.transport.node.enabled on my cluster and as predicted I cannot restart the nodes as the index searchguard/ac/ac is unavailable.
^[[2015-06-30 14:03:49,322][ERROR][com.floragunn.searchguard.service.SearchGuardConfigService] [worker-node] Try to refresh security configuration but it failed due to org.elasticsearch.action.NoShardAvailableActionException: [searchguard][4] null
org.elasticsearch.action.NoShardAvailableActionException: [searchguard][4] null
What should I do to ensure than I can restart from a "cold restart" when all the nodes are unavailable ?
Thank you and have a great day.
--
You received this message because you are subscribed to the Google Groups "Search Guard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com.
To post to this group, send email to search-guard@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/59cfd7d1-a682-4db5-acc1-400fe1a4b07a%40googlegroups.com\.
For more options, visit https://groups.google.com/d/optout\.