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.