Can plugin be written for TCP transport?

Hi I have been looking at the various transport plugins. Correct me if I am wrong but those are for the http rest interface... Can plugins be written for the node transport?

Bassically this leads to securing ES. My ES is definitely not public and I know i can use reverse proxies or one of the http plugins... But what about client/programs connecting directly as nodes?

Bassically I need user auth and some form of acl. SSL is secondary. Also need to be able to audit the user access. Dealing with credit card data. So I need to know 100% who is accessing the data.

So...
What are some good steps to secure my ES cluster!?

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/1ef17a07-bd72-4eee-a6b9-93ff8d0e7980%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

You can write a Java app to authorize access with JAAS and use a SOCKS
proxy to connect to an ES cluster in a private subnet. That is all a matter
of network configuration, there is nothing that requires the effort of an
extra ES plugin.

Jörg

On Wed, Aug 13, 2014 at 3:38 PM, John Smith java.dev.mtl@gmail.com wrote:

Hi I have been looking at the various transport plugins. Correct me if I
am wrong but those are for the http rest interface... Can plugins be
written for the node transport?

Bassically this leads to securing ES. My ES is definitely not public and I
know i can use reverse proxies or one of the http plugins... But what about
client/programs connecting directly as nodes?

Bassically I need user auth and some form of acl. SSL is secondary. Also
need to be able to audit the user access. Dealing with credit card data. So
I need to know 100% who is accessing the data.

So...
What are some good steps to secure my ES cluster!?

--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/1ef17a07-bd72-4eee-a6b9-93ff8d0e7980%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoF4QuX1OjHeiUOe-7VScPAGvjwB0MTWZnD6SE4nLCBS4g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

That's what I was thinking...

1- I would like this java app to use the node client, cause I like that
fact that there no extra hop and automatic failover to next node.
2- I figure it would be a firewall setting/socks to only allow the java app
to connect to ES. But again here anyone can go create a node client on the
same machine and pull data anonymously.

I know any one person can log in a machine at any time and any person can
read regardless and it's ok, the data is supposed to be read but at least
you know who read it and when. That's not an issue... Security is a best
effort, but the issue is the audit process and how well you can check if
all your eggs are there.

Even if I do exactly as you said, subnet plus socks proxy, someone can
still go to that machine create their own node client and bypass the java
app with no direct trace. This will probably never happen, but all it takes
is one angry employ.

On Wednesday, 13 August 2014 09:50:25 UTC-4, Jörg Prante wrote:

You can write a Java app to authorize access with JAAS and use a SOCKS
proxy to connect to an ES cluster in a private subnet. That is all a matter
of network configuration, there is nothing that requires the effort of an
extra ES plugin.

Jörg

On Wed, Aug 13, 2014 at 3:38 PM, John Smith <java.d...@gmail.com
<javascript:>> wrote:

Hi I have been looking at the various transport plugins. Correct me if I
am wrong but those are for the http rest interface... Can plugins be
written for the node transport?

Bassically this leads to securing ES. My ES is definitely not public and
I know i can use reverse proxies or one of the http plugins... But what
about client/programs connecting directly as nodes?

Bassically I need user auth and some form of acl. SSL is secondary. Also
need to be able to audit the user access. Dealing with credit card data. So
I need to know 100% who is accessing the data.

So...
What are some good steps to secure my ES cluster!?

--
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 elasticsearc...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/1ef17a07-bd72-4eee-a6b9-93ff8d0e7980%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

It would be cool if we could use something like Jetty plugin and disable
client access from the TCP node and only use the TCP node for cluster
related work.

On Wednesday, 13 August 2014 11:07:45 UTC-4, John Smith wrote:

That's what I was thinking...

1- I would like this java app to use the node client, cause I like that
fact that there no extra hop and automatic failover to next node.
2- I figure it would be a firewall setting/socks to only allow the java
app to connect to ES. But again here anyone can go create a node client on
the same machine and pull data anonymously.

I know any one person can log in a machine at any time and any person can
read regardless and it's ok, the data is supposed to be read but at least
you know who read it and when. That's not an issue... Security is a best
effort, but the issue is the audit process and how well you can check if
all your eggs are there.

Even if I do exactly as you said, subnet plus socks proxy, someone can
still go to that machine create their own node client and bypass the java
app with no direct trace. This will probably never happen, but all it takes
is one angry employ.

On Wednesday, 13 August 2014 09:50:25 UTC-4, Jörg Prante wrote:

You can write a Java app to authorize access with JAAS and use a SOCKS
proxy to connect to an ES cluster in a private subnet. That is all a matter
of network configuration, there is nothing that requires the effort of an
extra ES plugin.

Jörg

On Wed, Aug 13, 2014 at 3:38 PM, John Smith java.d...@gmail.com wrote:

Hi I have been looking at the various transport plugins. Correct me if I
am wrong but those are for the http rest interface... Can plugins be
written for the node transport?

Bassically this leads to securing ES. My ES is definitely not public and
I know i can use reverse proxies or one of the http plugins... But what
about client/programs connecting directly as nodes?

Bassically I need user auth and some form of acl. SSL is secondary. Also
need to be able to audit the user access. Dealing with credit card data. So
I need to know 100% who is accessing the data.

So...
What are some good steps to secure my ES cluster!?

--
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 elasticsearc...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/1ef17a07-bd72-4eee-a6b9-93ff8d0e7980%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/c7a7d241-575e-480c-afe9-e2ef69043160%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

With the configuration settings "transport.type" and
"transport.service.type"

Example:

transport.type:
org.xbib.elasticsearch.transport.syslog.netty.SyslogNettyTransportModule
transport.service.type:
org.xbib.elasticsearch.transport.syslog.SyslogTransportService

you can implement your own transport layer.

With this mechanism you can write plugins to create an audit trail of all
clients or nodes that connect to your cluster and you can log what they
did, for later revision. Or, you can add a registry for clients, add JAAS,
...

For example, I played with a modified netty transport layer to dump all
parsed transport actions between nodes to a remote host syslog, including
the action names and the channel connection information of local and remote
host/port.

On such a custom transport layer implementation, you can add even more low
level logic. If you do not want certain nodes or clients to connect, you
could a) use zen unicast for manual configuration of permitted nodes or
clients and/or b) reject all network actions from unknown/unregistered
clients, independent of discovery.

Note, manipulating transport layer is not free lunch and is not always fun.
Performance may degrade, other things may break etc.

Jörg

On Wed, Aug 13, 2014 at 5:07 PM, John Smith java.dev.mtl@gmail.com wrote:

That's what I was thinking...

1- I would like this java app to use the node client, cause I like that
fact that there no extra hop and automatic failover to next node.
2- I figure it would be a firewall setting/socks to only allow the java
app to connect to ES. But again here anyone can go create a node client on
the same machine and pull data anonymously.

I know any one person can log in a machine at any time and any person can
read regardless and it's ok, the data is supposed to be read but at least
you know who read it and when. That's not an issue... Security is a best
effort, but the issue is the audit process and how well you can check if
all your eggs are there.

Even if I do exactly as you said, subnet plus socks proxy, someone can
still go to that machine create their own node client and bypass the java
app with no direct trace. This will probably never happen, but all it takes
is one angry employ.

On Wednesday, 13 August 2014 09:50:25 UTC-4, Jörg Prante wrote:

You can write a Java app to authorize access with JAAS and use a SOCKS
proxy to connect to an ES cluster in a private subnet. That is all a matter
of network configuration, there is nothing that requires the effort of an
extra ES plugin.

Jörg

On Wed, Aug 13, 2014 at 3:38 PM, John Smith java.d...@gmail.com wrote:

Hi I have been looking at the various transport plugins. Correct me if I
am wrong but those are for the http rest interface... Can plugins be
written for the node transport?

Bassically this leads to securing ES. My ES is definitely not public and
I know i can use reverse proxies or one of the http plugins... But what
about client/programs connecting directly as nodes?

Bassically I need user auth and some form of acl. SSL is secondary. Also
need to be able to audit the user access. Dealing with credit card data. So
I need to know 100% who is accessing the data.

So...
What are some good steps to secure my ES cluster!?

--
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 elasticsearc...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/
msgid/elasticsearch/1ef17a07-bd72-4eee-a6b9-93ff8d0e7980%
40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com?utm_medium=email&utm_source=footer
.

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

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGXBVE4K0jGusJO-Ta0vcNZRZxiOxbfX4-E6_n%2BSLHMZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Hi thanks Jorg.

Just to be sure, creating a plugin and overriding: transport.type and
transport.service.type this allow us to create custom transport for TCP
9300 transport or the HTTP 9200 transport?

I don't have a problem with using

Subnet and firewall
And
Nginx or specified plugin.
Or
Custom application

To secure ES from outside world. In fact that's pretty good.

We run a web layer in DMZ and ES on a second layer. So only DMZ has access
to ES.

The question is how do you secure ES from the inside world? Anyone who has
access to the subnet and to the ES cluster can just login and install their
own "jobs" that can use port 9300 and do what ever they want with ES. Even
a simple authentication would be better then nothing here.

If what you said above allows us to replace 9300 transport, then awesome.
The issue is Elasticsearch has built the really nice fast Ferari but opted
out of providing even a simple door locking mechanism. Using nginx is like
telling your neighbor to keep an eye on your car while you are away on the
weekend and trusting they will do right.

On Wednesday, 13 August 2014 14:21:01 UTC-4, Jörg Prante wrote:

With the configuration settings "transport.type" and
"transport.service.type"

Example:

transport.type:
org.xbib.elasticsearch.transport.syslog.netty.SyslogNettyTransportModule
transport.service.type:
org.xbib.elasticsearch.transport.syslog.SyslogTransportService

you can implement your own transport layer.

With this mechanism you can write plugins to create an audit trail of all
clients or nodes that connect to your cluster and you can log what they
did, for later revision. Or, you can add a registry for clients, add JAAS,
...

For example, I played with a modified netty transport layer to dump all
parsed transport actions between nodes to a remote host syslog, including
the action names and the channel connection information of local and remote
host/port.

On such a custom transport layer implementation, you can add even more low
level logic. If you do not want certain nodes or clients to connect, you
could a) use zen unicast for manual configuration of permitted nodes or
clients and/or b) reject all network actions from unknown/unregistered
clients, independent of discovery.

Note, manipulating transport layer is not free lunch and is not always
fun. Performance may degrade, other things may break etc.

Jörg

On Wed, Aug 13, 2014 at 5:07 PM, John Smith <java.d...@gmail.com
<javascript:>> wrote:

That's what I was thinking...

1- I would like this java app to use the node client, cause I like that
fact that there no extra hop and automatic failover to next node.
2- I figure it would be a firewall setting/socks to only allow the java
app to connect to ES. But again here anyone can go create a node client on
the same machine and pull data anonymously.

I know any one person can log in a machine at any time and any person can
read regardless and it's ok, the data is supposed to be read but at least
you know who read it and when. That's not an issue... Security is a best
effort, but the issue is the audit process and how well you can check if
all your eggs are there.

Even if I do exactly as you said, subnet plus socks proxy, someone can
still go to that machine create their own node client and bypass the java
app with no direct trace. This will probably never happen, but all it takes
is one angry employ.

On Wednesday, 13 August 2014 09:50:25 UTC-4, Jörg Prante wrote:

You can write a Java app to authorize access with JAAS and use a SOCKS
proxy to connect to an ES cluster in a private subnet. That is all a matter
of network configuration, there is nothing that requires the effort of an
extra ES plugin.

Jörg

On Wed, Aug 13, 2014 at 3:38 PM, John Smith java.d...@gmail.com wrote:

Hi I have been looking at the various transport plugins. Correct me if
I am wrong but those are for the http rest interface... Can plugins be
written for the node transport?

Bassically this leads to securing ES. My ES is definitely not public
and I know i can use reverse proxies or one of the http plugins... But what
about client/programs connecting directly as nodes?

Bassically I need user auth and some form of acl. SSL is secondary.
Also need to be able to audit the user access. Dealing with credit card
data. So I need to know 100% who is accessing the data.

So...
What are some good steps to secure my ES cluster!?

--
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 elasticsearc...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/
msgid/elasticsearch/1ef17a07-bd72-4eee-a6b9-93ff8d0e7980%
40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 elasticsearc...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com?utm_medium=email&utm_source=footer
.

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

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/353287e7-16ba-4eb0-abcc-d632f5f98f13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

I think what allot of people is more like this? If I understand
correctly... This runs above the 9300 transport. So you still get all the
goodies/zen discovery etc... Plus added authentication. Except this only
works with found...

On Wednesday, 13 August 2014 15:23:05 UTC-4, John Smith wrote:

Hi thanks Jorg.

Just to be sure, creating a plugin and overriding: transport.type and
transport.service.type this allow us to create custom transport for TCP
9300 transport or the HTTP 9200 transport?

I don't have a problem with using

Subnet and firewall
And
Nginx or specified plugin.
Or
Custom application

To secure ES from outside world. In fact that's pretty good.

We run a web layer in DMZ and ES on a second layer. So only DMZ has access
to ES.

The question is how do you secure ES from the inside world? Anyone who has
access to the subnet and to the ES cluster can just login and install their
own "jobs" that can use port 9300 and do what ever they want with ES. Even
a simple authentication would be better then nothing here.

If what you said above allows us to replace 9300 transport, then awesome.
The issue is Elasticsearch has built the really nice fast Ferari but opted
out of providing even a simple door locking mechanism. Using nginx is like
telling your neighbor to keep an eye on your car while you are away on the
weekend and trusting they will do right.

On Wednesday, 13 August 2014 14:21:01 UTC-4, Jörg Prante wrote:

With the configuration settings "transport.type" and
"transport.service.type"

Example:

transport.type:
org.xbib.elasticsearch.transport.syslog.netty.SyslogNettyTransportModule
transport.service.type:
org.xbib.elasticsearch.transport.syslog.SyslogTransportService

you can implement your own transport layer.

With this mechanism you can write plugins to create an audit trail of all
clients or nodes that connect to your cluster and you can log what they
did, for later revision. Or, you can add a registry for clients, add JAAS,
...

For example, I played with a modified netty transport layer to dump all
parsed transport actions between nodes to a remote host syslog, including
the action names and the channel connection information of local and remote
host/port.

On such a custom transport layer implementation, you can add even more
low level logic. If you do not want certain nodes or clients to connect,
you could a) use zen unicast for manual configuration of permitted nodes or
clients and/or b) reject all network actions from unknown/unregistered
clients, independent of discovery.

Note, manipulating transport layer is not free lunch and is not always
fun. Performance may degrade, other things may break etc.

Jörg

On Wed, Aug 13, 2014 at 5:07 PM, John Smith java.d...@gmail.com wrote:

That's what I was thinking...

1- I would like this java app to use the node client, cause I like that
fact that there no extra hop and automatic failover to next node.
2- I figure it would be a firewall setting/socks to only allow the java
app to connect to ES. But again here anyone can go create a node client on
the same machine and pull data anonymously.

I know any one person can log in a machine at any time and any person
can read regardless and it's ok, the data is supposed to be read but at
least you know who read it and when. That's not an issue... Security is a
best effort, but the issue is the audit process and how well you can check
if all your eggs are there.

Even if I do exactly as you said, subnet plus socks proxy, someone can
still go to that machine create their own node client and bypass the java
app with no direct trace. This will probably never happen, but all it takes
is one angry employ.

On Wednesday, 13 August 2014 09:50:25 UTC-4, Jörg Prante wrote:

You can write a Java app to authorize access with JAAS and use a SOCKS
proxy to connect to an ES cluster in a private subnet. That is all a matter
of network configuration, there is nothing that requires the effort of an
extra ES plugin.

Jörg

On Wed, Aug 13, 2014 at 3:38 PM, John Smith java.d...@gmail.com
wrote:

Hi I have been looking at the various transport plugins. Correct me if
I am wrong but those are for the http rest interface... Can plugins be
written for the node transport?

Bassically this leads to securing ES. My ES is definitely not public
and I know i can use reverse proxies or one of the http plugins... But what
about client/programs connecting directly as nodes?

Bassically I need user auth and some form of acl. SSL is secondary.
Also need to be able to audit the user access. Dealing with credit card
data. So I need to know 100% who is accessing the data.

So...
What are some good steps to secure my ES cluster!?

--
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 elasticsearc...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/
msgid/elasticsearch/1ef17a07-bd72-4eee-a6b9-93ff8d0e7980%
40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 elasticsearc...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com?utm_medium=email&utm_source=footer
.

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

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/68e0b7c5-a67e-447b-b938-fce0d5a2bf5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Yes, you can reimplement the transport layer. The config setting runs
beyond the transport layer and if you get into a mood you could even throw
port 9300 and all the netty code away. Not that I recommend it - but this
is a very low-level, dark magic intrusion into the ES guts. You can break
everything into pieces, including breaking the discovery basics etc.

Jörg

On Wed, Aug 13, 2014 at 9:52 PM, John Smith java.dev.mtl@gmail.com wrote:

I think what allot of people is more like this? If I understand
correctly... This runs above the 9300 transport. So you still get all the
goodies/zen discovery etc... Plus added authentication. Except this only
works with found...

On Wednesday, 13 August 2014 15:23:05 UTC-4, John Smith wrote:

Hi thanks Jorg.

Just to be sure, creating a plugin and overriding: transport.type and
transport.service.type this allow us to create custom transport for TCP
9300 transport or the HTTP 9200 transport?

I don't have a problem with using

Subnet and firewall
And
Nginx or specified plugin.
Or
Custom application

To secure ES from outside world. In fact that's pretty good.

We run a web layer in DMZ and ES on a second layer. So only DMZ has
access to ES.

The question is how do you secure ES from the inside world? Anyone who
has access to the subnet and to the ES cluster can just login and install
their own "jobs" that can use port 9300 and do what ever they want with ES.
Even a simple authentication would be better then nothing here.

If what you said above allows us to replace 9300 transport, then awesome.
The issue is Elasticsearch has built the really nice fast Ferari but opted
out of providing even a simple door locking mechanism. Using nginx is like
telling your neighbor to keep an eye on your car while you are away on the
weekend and trusting they will do right.

On Wednesday, 13 August 2014 14:21:01 UTC-4, Jörg Prante wrote:

With the configuration settings "transport.type" and
"transport.service.type"

Example:

transport.type: org.xbib.elasticsearch.transport.syslog.netty.
SyslogNettyTransportModule
transport.service.type: org.xbib.elasticsearch.transport.syslog.
SyslogTransportService

you can implement your own transport layer.

With this mechanism you can write plugins to create an audit trail of
all clients or nodes that connect to your cluster and you can log what they
did, for later revision. Or, you can add a registry for clients, add JAAS,
...

For example, I played with a modified netty transport layer to dump all
parsed transport actions between nodes to a remote host syslog, including
the action names and the channel connection information of local and remote
host/port.

On such a custom transport layer implementation, you can add even more
low level logic. If you do not want certain nodes or clients to connect,
you could a) use zen unicast for manual configuration of permitted nodes or
clients and/or b) reject all network actions from unknown/unregistered
clients, independent of discovery.

Note, manipulating transport layer is not free lunch and is not always
fun. Performance may degrade, other things may break etc.

Jörg

On Wed, Aug 13, 2014 at 5:07 PM, John Smith java.d...@gmail.com wrote:

That's what I was thinking...

1- I would like this java app to use the node client, cause I like that
fact that there no extra hop and automatic failover to next node.
2- I figure it would be a firewall setting/socks to only allow the java
app to connect to ES. But again here anyone can go create a node client on
the same machine and pull data anonymously.

I know any one person can log in a machine at any time and any person
can read regardless and it's ok, the data is supposed to be read but at
least you know who read it and when. That's not an issue... Security is a
best effort, but the issue is the audit process and how well you can check
if all your eggs are there.

Even if I do exactly as you said, subnet plus socks proxy, someone can
still go to that machine create their own node client and bypass the java
app with no direct trace. This will probably never happen, but all it takes
is one angry employ.

On Wednesday, 13 August 2014 09:50:25 UTC-4, Jörg Prante wrote:

You can write a Java app to authorize access with JAAS and use a SOCKS
proxy to connect to an ES cluster in a private subnet. That is all a matter
of network configuration, there is nothing that requires the effort of an
extra ES plugin.

Jörg

On Wed, Aug 13, 2014 at 3:38 PM, John Smith java.d...@gmail.com
wrote:

Hi I have been looking at the various transport plugins. Correct me
if I am wrong but those are for the http rest interface... Can plugins be
written for the node transport?

Bassically this leads to securing ES. My ES is definitely not public
and I know i can use reverse proxies or one of the http plugins... But what
about client/programs connecting directly as nodes?

Bassically I need user auth and some form of acl. SSL is secondary.
Also need to be able to audit the user access. Dealing with credit card
data. So I need to know 100% who is accessing the data.

So...
What are some good steps to secure my ES cluster!?

--
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 elasticsearc...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/
msgid/elasticsearch/1ef17a07-bd72-4eee-a6b9-93ff8d0e7980%40goo
glegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 elasticsearc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%
40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com?utm_medium=email&utm_source=footer
.

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

--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/68e0b7c5-a67e-447b-b938-fce0d5a2bf5f%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/68e0b7c5-a67e-447b-b938-fce0d5a2bf5f%40googlegroups.com?utm_medium=email&utm_source=footer
.

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

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGRd7gdztL4rn7mavmx0fCUEn%3DG7A9_T3FdC__42PM2Aw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Yeah I tried the foundit plugin and just striped away all their code and
it's just a pass through! But would def need to figure out the inards.

We have web app in dmz and then ES at lower level. But again it's about
protecting from the inside. When having a bunch of support staff that are
capable of accessing the box for admin purposes and support... My admin guy
is a smart dude and he understands you can only go so far! We just have to
see if it's acceptable.

On Thursday, 14 August 2014 14:54:51 UTC-4, Jörg Prante wrote:

Yes, you can reimplement the transport layer. The config setting runs
beyond the transport layer and if you get into a mood you could even throw
port 9300 and all the netty code away. Not that I recommend it - but this
is a very low-level, dark magic intrusion into the ES guts. You can break
everything into pieces, including breaking the discovery basics etc.

Jörg

On Wed, Aug 13, 2014 at 9:52 PM, John Smith <java.d...@gmail.com
<javascript:>> wrote:

I think what allot of people is more like this? If I understand
correctly... This runs above the 9300 transport. So you still get all the
goodies/zen discovery etc... Plus added authentication. Except this only
works with found...

On Wednesday, 13 August 2014 15:23:05 UTC-4, John Smith wrote:

Hi thanks Jorg.

Just to be sure, creating a plugin and overriding: transport.type and
transport.service.type this allow us to create custom transport for TCP
9300 transport or the HTTP 9200 transport?

I don't have a problem with using

Subnet and firewall
And
Nginx or specified plugin.
Or
Custom application

To secure ES from outside world. In fact that's pretty good.

We run a web layer in DMZ and ES on a second layer. So only DMZ has
access to ES.

The question is how do you secure ES from the inside world? Anyone who
has access to the subnet and to the ES cluster can just login and install
their own "jobs" that can use port 9300 and do what ever they want with ES.
Even a simple authentication would be better then nothing here.

If what you said above allows us to replace 9300 transport, then
awesome. The issue is Elasticsearch has built the really nice fast Ferari
but opted out of providing even a simple door locking mechanism. Using
nginx is like telling your neighbor to keep an eye on your car while you
are away on the weekend and trusting they will do right.

On Wednesday, 13 August 2014 14:21:01 UTC-4, Jörg Prante wrote:

With the configuration settings "transport.type" and
"transport.service.type"

Example:

transport.type: org.xbib.elasticsearch.transport.syslog.netty.
SyslogNettyTransportModule
transport.service.type: org.xbib.elasticsearch.transport.syslog.
SyslogTransportService

you can implement your own transport layer.

With this mechanism you can write plugins to create an audit trail of
all clients or nodes that connect to your cluster and you can log what they
did, for later revision. Or, you can add a registry for clients, add JAAS,
...

For example, I played with a modified netty transport layer to dump all
parsed transport actions between nodes to a remote host syslog, including
the action names and the channel connection information of local and remote
host/port.

On such a custom transport layer implementation, you can add even more
low level logic. If you do not want certain nodes or clients to connect,
you could a) use zen unicast for manual configuration of permitted nodes or
clients and/or b) reject all network actions from unknown/unregistered
clients, independent of discovery.

Note, manipulating transport layer is not free lunch and is not always
fun. Performance may degrade, other things may break etc.

Jörg

On Wed, Aug 13, 2014 at 5:07 PM, John Smith java.d...@gmail.com
wrote:

That's what I was thinking...

1- I would like this java app to use the node client, cause I like
that fact that there no extra hop and automatic failover to next node.
2- I figure it would be a firewall setting/socks to only allow the
java app to connect to ES. But again here anyone can go create a node
client on the same machine and pull data anonymously.

I know any one person can log in a machine at any time and any person
can read regardless and it's ok, the data is supposed to be read but at
least you know who read it and when. That's not an issue... Security is a
best effort, but the issue is the audit process and how well you can check
if all your eggs are there.

Even if I do exactly as you said, subnet plus socks proxy, someone can
still go to that machine create their own node client and bypass the java
app with no direct trace. This will probably never happen, but all it takes
is one angry employ.

On Wednesday, 13 August 2014 09:50:25 UTC-4, Jörg Prante wrote:

You can write a Java app to authorize access with JAAS and use a
SOCKS proxy to connect to an ES cluster in a private subnet. That is all a
matter of network configuration, there is nothing that requires the effort
of an extra ES plugin.

Jörg

On Wed, Aug 13, 2014 at 3:38 PM, John Smith java.d...@gmail.com
wrote:

Hi I have been looking at the various transport plugins. Correct me
if I am wrong but those are for the http rest interface... Can plugins be
written for the node transport?

Bassically this leads to securing ES. My ES is definitely not public
and I know i can use reverse proxies or one of the http plugins... But what
about client/programs connecting directly as nodes?

Bassically I need user auth and some form of acl. SSL is secondary.
Also need to be able to audit the user access. Dealing with credit card
data. So I need to know 100% who is accessing the data.

So...
What are some good steps to secure my ES cluster!?

--
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 elasticsearc...@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/1ef17a07-bd7
2-4eee-a6b9-93ff8d0e7980%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 elasticsearc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%
40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com?utm_medium=email&utm_source=footer
.

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

--
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 elasticsearc...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/68e0b7c5-a67e-447b-b938-fce0d5a2bf5f%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/68e0b7c5-a67e-447b-b938-fce0d5a2bf5f%40googlegroups.com?utm_medium=email&utm_source=footer
.

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

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/272e8550-9967-4977-92ad-625622e433e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

You can not protect from superuser access from within an app, except when
you are also a superuser, and can create obscure kernel capabilities to
protect an app from another superuser.

Usually this is not solvable by technical solutions, it is a matter of
trust into the infrastructure (data center, network, staff).

Jörg

On Fri, Aug 15, 2014 at 12:03 AM, John Smith java.dev.mtl@gmail.com wrote:

Yeah I tried the foundit plugin and just striped away all their code and
it's just a pass through! But would def need to figure out the inards.

We have web app in dmz and then ES at lower level. But again it's about
protecting from the inside. When having a bunch of support staff that are
capable of accessing the box for admin purposes and support... My admin guy
is a smart dude and he understands you can only go so far! We just have to
see if it's acceptable.

On Thursday, 14 August 2014 14:54:51 UTC-4, Jörg Prante wrote:

Yes, you can reimplement the transport layer. The config setting runs
beyond the transport layer and if you get into a mood you could even throw
port 9300 and all the netty code away. Not that I recommend it - but this
is a very low-level, dark magic intrusion into the ES guts. You can break
everything into pieces, including breaking the discovery basics etc.

Jörg

On Wed, Aug 13, 2014 at 9:52 PM, John Smith java.d...@gmail.com wrote:

I think what allot of people is more like this? If I understand
correctly... This runs above the 9300 transport. So you still get all the
goodies/zen discovery etc... Plus added authentication. Except this only
works with found...

On Wednesday, 13 August 2014 15:23:05 UTC-4, John Smith wrote:

Hi thanks Jorg.

Just to be sure, creating a plugin and overriding: transport.type and
transport.service.type this allow us to create custom transport for TCP
9300 transport or the HTTP 9200 transport?

I don't have a problem with using

Subnet and firewall
And
Nginx or specified plugin.
Or
Custom application

To secure ES from outside world. In fact that's pretty good.

We run a web layer in DMZ and ES on a second layer. So only DMZ has
access to ES.

The question is how do you secure ES from the inside world? Anyone who
has access to the subnet and to the ES cluster can just login and install
their own "jobs" that can use port 9300 and do what ever they want with ES.
Even a simple authentication would be better then nothing here.

If what you said above allows us to replace 9300 transport, then
awesome. The issue is Elasticsearch has built the really nice fast Ferari
but opted out of providing even a simple door locking mechanism. Using
nginx is like telling your neighbor to keep an eye on your car while you
are away on the weekend and trusting they will do right.

On Wednesday, 13 August 2014 14:21:01 UTC-4, Jörg Prante wrote:

With the configuration settings "transport.type" and
"transport.service.type"

Example:

transport.type: org.xbib.elasticsearch.transport.syslog.netty.
SyslogNettyTransportModule
transport.service.type: org.xbib.elasticsearch.transport.syslog.
SyslogTransportService

you can implement your own transport layer.

With this mechanism you can write plugins to create an audit trail of
all clients or nodes that connect to your cluster and you can log what they
did, for later revision. Or, you can add a registry for clients, add JAAS,
...

For example, I played with a modified netty transport layer to dump
all parsed transport actions between nodes to a remote host syslog,
including the action names and the channel connection information of local
and remote host/port.

On such a custom transport layer implementation, you can add even more
low level logic. If you do not want certain nodes or clients to connect,
you could a) use zen unicast for manual configuration of permitted nodes or
clients and/or b) reject all network actions from unknown/unregistered
clients, independent of discovery.

Note, manipulating transport layer is not free lunch and is not always
fun. Performance may degrade, other things may break etc.

Jörg

On Wed, Aug 13, 2014 at 5:07 PM, John Smith java.d...@gmail.com
wrote:

That's what I was thinking...

1- I would like this java app to use the node client, cause I like
that fact that there no extra hop and automatic failover to next node.
2- I figure it would be a firewall setting/socks to only allow the
java app to connect to ES. But again here anyone can go create a node
client on the same machine and pull data anonymously.

I know any one person can log in a machine at any time and any person
can read regardless and it's ok, the data is supposed to be read but at
least you know who read it and when. That's not an issue... Security is a
best effort, but the issue is the audit process and how well you can check
if all your eggs are there.

Even if I do exactly as you said, subnet plus socks proxy, someone
can still go to that machine create their own node client and bypass the
java app with no direct trace. This will probably never happen, but all it
takes is one angry employ.

On Wednesday, 13 August 2014 09:50:25 UTC-4, Jörg Prante wrote:

You can write a Java app to authorize access with JAAS and use a
SOCKS proxy to connect to an ES cluster in a private subnet. That is all a
matter of network configuration, there is nothing that requires the effort
of an extra ES plugin.

Jörg

On Wed, Aug 13, 2014 at 3:38 PM, John Smith java.d...@gmail.com
wrote:

Hi I have been looking at the various transport plugins. Correct me
if I am wrong but those are for the http rest interface... Can plugins be
written for the node transport?

Bassically this leads to securing ES. My ES is definitely not
public and I know i can use reverse proxies or one of the http plugins...
But what about client/programs connecting directly as nodes?

Bassically I need user auth and some form of acl. SSL is secondary.
Also need to be able to audit the user access. Dealing with credit card
data. So I need to know 100% who is accessing the data.

So...
What are some good steps to secure my ES cluster!?

--
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 elasticsearc...@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/1ef17a07-bd7
2-4eee-a6b9-93ff8d0e7980%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 elasticsearc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40goo
glegroups.com
https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com?utm_medium=email&utm_source=footer
.

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

--
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 elasticsearc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/elasticsearch/68e0b7c5-a67e-447b-b938-fce0d5a2bf5f%
40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/68e0b7c5-a67e-447b-b938-fce0d5a2bf5f%40googlegroups.com?utm_medium=email&utm_source=footer
.

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

--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/272e8550-9967-4977-92ad-625622e433e6%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/272e8550-9967-4977-92ad-625622e433e6%40googlegroups.com?utm_medium=email&utm_source=footer
.

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

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHHL6nZLsR-YZf5vnjZYzhtFW5pwZqU3S5dzGKBpYJ4PA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Of course understood.

I think subnetting/double firewall.

DMZ will not have access to 9300 and internal network will not have access
to 9300 only subnet for ES cluster functions.

On Friday, 15 August 2014 05:04:35 UTC-4, Jörg Prante wrote:

You can not protect from superuser access from within an app, except when
you are also a superuser, and can create obscure kernel capabilities to
protect an app from another superuser.

Usually this is not solvable by technical solutions, it is a matter of
trust into the infrastructure (data center, network, staff).

Jörg

On Fri, Aug 15, 2014 at 12:03 AM, John Smith <java.d...@gmail.com
<javascript:>> wrote:

Yeah I tried the foundit plugin and just striped away all their code and
it's just a pass through! But would def need to figure out the inards.

We have web app in dmz and then ES at lower level. But again it's about
protecting from the inside. When having a bunch of support staff that are
capable of accessing the box for admin purposes and support... My admin guy
is a smart dude and he understands you can only go so far! We just have to
see if it's acceptable.

On Thursday, 14 August 2014 14:54:51 UTC-4, Jörg Prante wrote:

Yes, you can reimplement the transport layer. The config setting runs
beyond the transport layer and if you get into a mood you could even throw
port 9300 and all the netty code away. Not that I recommend it - but this
is a very low-level, dark magic intrusion into the ES guts. You can break
everything into pieces, including breaking the discovery basics etc.

Jörg

On Wed, Aug 13, 2014 at 9:52 PM, John Smith java.d...@gmail.com wrote:

I think what allot of people is more like this? If I understand
correctly... This runs above the 9300 transport. So you still get all the
goodies/zen discovery etc... Plus added authentication. Except this only
works with found...

On Wednesday, 13 August 2014 15:23:05 UTC-4, John Smith wrote:

Hi thanks Jorg.

Just to be sure, creating a plugin and overriding: transport.type and
transport.service.type this allow us to create custom transport for TCP
9300 transport or the HTTP 9200 transport?

I don't have a problem with using

Subnet and firewall
And
Nginx or specified plugin.
Or
Custom application

To secure ES from outside world. In fact that's pretty good.

We run a web layer in DMZ and ES on a second layer. So only DMZ has
access to ES.

The question is how do you secure ES from the inside world? Anyone who
has access to the subnet and to the ES cluster can just login and install
their own "jobs" that can use port 9300 and do what ever they want with ES.
Even a simple authentication would be better then nothing here.

If what you said above allows us to replace 9300 transport, then
awesome. The issue is Elasticsearch has built the really nice fast Ferari
but opted out of providing even a simple door locking mechanism. Using
nginx is like telling your neighbor to keep an eye on your car while you
are away on the weekend and trusting they will do right.

On Wednesday, 13 August 2014 14:21:01 UTC-4, Jörg Prante wrote:

With the configuration settings "transport.type" and
"transport.service.type"

Example:

transport.type: org.xbib.elasticsearch.transport.syslog.netty.
SyslogNettyTransportModule
transport.service.type: org.xbib.elasticsearch.transport.syslog.
SyslogTransportService

you can implement your own transport layer.

With this mechanism you can write plugins to create an audit trail of
all clients or nodes that connect to your cluster and you can log what they
did, for later revision. Or, you can add a registry for clients, add JAAS,
...

For example, I played with a modified netty transport layer to dump
all parsed transport actions between nodes to a remote host syslog,
including the action names and the channel connection information of local
and remote host/port.

On such a custom transport layer implementation, you can add even
more low level logic. If you do not want certain nodes or clients to
connect, you could a) use zen unicast for manual configuration of permitted
nodes or clients and/or b) reject all network actions from
unknown/unregistered clients, independent of discovery.

Note, manipulating transport layer is not free lunch and is not
always fun. Performance may degrade, other things may break etc.

Jörg

On Wed, Aug 13, 2014 at 5:07 PM, John Smith java.d...@gmail.com
wrote:

That's what I was thinking...

1- I would like this java app to use the node client, cause I like
that fact that there no extra hop and automatic failover to next node.
2- I figure it would be a firewall setting/socks to only allow the
java app to connect to ES. But again here anyone can go create a node
client on the same machine and pull data anonymously.

I know any one person can log in a machine at any time and any
person can read regardless and it's ok, the data is supposed to be read but
at least you know who read it and when. That's not an issue... Security is
a best effort, but the issue is the audit process and how well you can
check if all your eggs are there.

Even if I do exactly as you said, subnet plus socks proxy, someone
can still go to that machine create their own node client and bypass the
java app with no direct trace. This will probably never happen, but all it
takes is one angry employ.

On Wednesday, 13 August 2014 09:50:25 UTC-4, Jörg Prante wrote:

You can write a Java app to authorize access with JAAS and use a
SOCKS proxy to connect to an ES cluster in a private subnet. That is all a
matter of network configuration, there is nothing that requires the effort
of an extra ES plugin.

Jörg

On Wed, Aug 13, 2014 at 3:38 PM, John Smith java.d...@gmail.com
wrote:

Hi I have been looking at the various transport plugins. Correct
me if I am wrong but those are for the http rest interface... Can plugins
be written for the node transport?

Bassically this leads to securing ES. My ES is definitely not
public and I know i can use reverse proxies or one of the http plugins...
But what about client/programs connecting directly as nodes?

Bassically I need user auth and some form of acl. SSL is
secondary. Also need to be able to audit the user access. Dealing with
credit card data. So I need to know 100% who is accessing the data.

So...
What are some good steps to secure my ES cluster!?

--
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 elasticsearc...@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/1ef17a07-bd7
2-4eee-a6b9-93ff8d0e7980%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 elasticsearc...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8
b-43c8-b818-4f942a02daf5%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com?utm_medium=email&utm_source=footer
.

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

--
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 elasticsearc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/elasticsearch/68e0b7c5-a67e-447b-b938-fce0d5a2bf5f%
40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/68e0b7c5-a67e-447b-b938-fce0d5a2bf5f%40googlegroups.com?utm_medium=email&utm_source=footer
.

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

--
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 elasticsearc...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/272e8550-9967-4977-92ad-625622e433e6%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/272e8550-9967-4977-92ad-625622e433e6%40googlegroups.com?utm_medium=email&utm_source=footer
.

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

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/7e43e349-7403-41da-a3ab-cf5ad2e3e3e7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.