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+unsubscr...@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.

Reply via email to