Authenticating clients with ES plugin


(Jordan) #1

Hi, I recently became a ror enterprise customer for the kibana plugin and I have already setup ES plugin on my 6.5.4 ES cluster. I followed the docs to enable basic auth which worked fine.
My question is for elasticsearch we are using fluentd for most hosts to write data into elasticsearch. For the basic auth case I can just put in the user:pass there and it will work fine, however I wanted to know if for writing data into ES does the plugin support PKI ?
Also, what logging clients do people use if they setup JWT? I use fluentd for example but i’m still investigating what needs to be changed to support the Authorization: Bearer token in the header from the fluent-plugin-elasticsearch for it to work with a cluster using readonlyrest and jwt as the auth for ES cluster

Thanks,


(Simone Scarduzio) #2

Hi @jordo1138, welcome to the forum! ReadonlyREST SSL feature is not (yet) configurable to require validation of the client certificate. However it could be done if required.

About the credentials passing, a good enough solution for machine-to-machine authentication is using auth_key_sha512 rule to store basic auth credentials in a hashed format inside ROR, provided that you enable SSL using a valid certificate.

The JWT authentication (with “Bearer” token) is supported by ReadonlyREST, but I could not find anything similar for fluentd. Not an expert though.

Not sure the bearer token would add much though. At the end of the day, between machines, you are always going to store a secret in the client side, and transmit it over https. Of course the scenario would be different if the JWT token would be created on the fly after a web authentication flow, but it’s not this the case apparently.

Other customers so far used Elastic’s log shippers like Logstash and Beats.


(Jordan) #3

Thanks I’ll look into the auth_keysha512 for fluentd writing into our cluster also.
I’m working with a contributor who helped me add a patch to allow JWT header sent from fluentd, but you’re right we’d have to manage the jwt generation separately.
Thanks