I don’t think you can just say that when a plugin is compatible with X-Pack it is also compatible with Search Guard. Search Guard is completely independent from X-Pack, so the implementations are most likely very, very different. Since X-Pack is closed source there’s no way to tell where the two implementations might be compatible and where not. We simply don’t know any of the internals of X-Pack.
Some of the more general advises surely also apply for Search Guard, like, do not listen on raw sockets, or the naming conventions for action requests. But in the end, I think there’s no way around testing your plugin with both X-Pack and Search Guard.
At the moment there’s no corresponding guide for Search Guard, but if we get more requests we can think about publishing something similar. It was just not something people actively asked for.
Might I ask what kind of plugin you are writing, and where you think it might conflict with Search Guard?
On Thursday, April 12, 2018 at 3:45:40 AM UTC-7, Lukáš Vlček wrote:
The following blog post puts out some information about what ES plugin authors should pay attention to if they want their plugin to be working well with X-Pack security (although the post itself highlights the fact that the ES plugin API is not stabilized). Is there any similar info for SG? Or let’s ask in a different way: Would it be possible to say that if ES plugin follows the mentioned recommendations and is compatible with X-Pack security then it will be working well with SG as well (and/or vice versa? I.e. is working well with SG thus is compatible with X-Pack too).