Elasticsearch nodes with X-Pack-Security and SG-Security nodes in the same cluster

Hi there.

I’m going to migrate X-Pack-Security feature to SG-Security (but using all the others X-Pack features).

Is possible (using the same PKI - PKCS12 files in all nodes X-Pack and SG) the nodes communicate each others? How do you guys will migrate in that scenario?

I’m thinking using cluster.routing.allocation (Cluster-level shard allocation filtering | Elasticsearch Guide [8.4] | Elastic) to push data to SG nodes and at the end recreate all user-accounts and roles and remove the old x-pack ones.

I’m afraid just changing the security stuff and cluster goes RED or impossible to rollback. So, adding more nodes in the same cluster sounds a good strategy.

So, what do you suggest?

Regards.

There is no turn-key solution. I would try to configure SG on a test cluster first. How big is the cluster? What authentication do you plan to use, internal DB?

using the same PKI - PKCS12 files in all nodes X-Pack and SG

You can use the same TLS certificates or create new certificates using SG TLS tool

The SG documentation Adding users | Security for Elasticsearch | Search Guard

I think using SG and X-Pack security on the same cluster will not work. While I have no specific knowledge about the X-Pack security inner workings, it is almost certain that both plugins use different approaches when it comes to inter-node communication.

The certificates are probably the smallest issue here. Search Guard also supports PKCS12 style certificates. However, we require that the node certificate have both serverAuth and clientAuth in the extended key usage field of the certificate. If X-Pack also requires this, I don’t know.

The main problem here is that for inter-cluster / node-to-node communication information about the user, roles and permissions have to be exchanged from node to node. It is almost certain that X-Pack does not understand the Search Guard format and vice-versa.

So while it might be technically possible that an X-Pack secured node can communicate with an SG-secured node regarding TLS, you will run into problems when the nodes actually try to exchange information. This might be solvable by using shard allocation and moving data to the new nodes, but to be honest, this has not been tried.

I would strongly suggest to migrate by doing a full cluster restart and prepare anything upfront on a staging / pre-prod system to minimize downtime.