Incompatibility with ECK (official elastic operator for Kubernetes deployment)

[Abhisek Mishra]

Installing the readonlyrest plugin and running a default cluster using the official elasticsearch operator (ECK) doesn't work, as requests made by the operator are rejected by ROR.

Asking around in the elastic forums I got to know that the operator uses two users in the file realm, namely "elastic-internal" and "elastic-internal-keystore" (see here)

This is a complete blocker for us as I couldn't find any way in ROR to allow requests from particular file realm users. (Also, we love the awesome support for JWT based auth, and would really like to continue using it)

Any help on this would be greatly appreciated

[Aljoscha Pörtner]

Same here 👍

[Mateusz Kołodziejczyk]

At the moment we are testing our official solution for ECK. This is still in alpha but if you are interested in testing it please reach us on https://forum.readonlyrest.com/

[Aljoscha Pörtner]

Thank you. Is it already on develop or master?

[Mateusz Kołodziejczyk]

On develop. But the solution won't be deployed as ES plugin, but rather as a proxy between Kibana and ECK node.

[Mateusz Kołodziejczyk]

https://forum.readonlyrest.com/t/has-ror-ability-to-work-with-azure-active-directory-and-eck-operator/2030/8?u=coutopl

[Mateusz Kołodziejczyk]

The ECK is supported starting from ROR 1.50.0. You have to enable xpack security (xpack.security.enabled: true) and patch Elasticsearch after installing ROR. Moreover, you have to use xpack security SSL for HTTP and transport.