Secure data exchange between A12 instances

Hello,
for a public tender, we are supposed to illustrate how two A12 instances can exchange data/documents in a secured way. It is important that transport and content are encrypted. Does anyone have experience or is there already an available solution?

Thanks,
Guido

Hi @guido-quiet-root ,

There is a ticket <INTERNAL_LINK> that mentiones similar topic. I believe that you should either add your use-case there or create another ticket where we would have to take a look at our clients to make sure that all the content is encrypted. As of today there is no solution for this requirement

Hi Tomas,
just to clarify <INTERNAL_LINK> is about the internal communication of the A12 components (like Data Services, Camunda, Solr, …). I’m talking about two different/separate A12 installations. At the moment we don’t have that requirement, just a customer inquiry.

Thanks,
Guido

Could you please explain why https between both instances is not enough? If A wants data from B it just uses https://B/api/... and the other way round B uses https://A/api/....

At what exact point does the https termination need to be? Is it on the load balancer on A and on B or somewhere else?

@andreas-fresh-mesa

Could you please explain why https between both instances is not enough? If A wants data from B it just uses https://B/api/... and the other way round B uses https://A/api/... .

HTTPS is only transport encryption, the customer wants content-encryption also. The customer had suggested FIT-Connect as a solution, where the data is encrypted end-to-end. I am looking for something similar.

Thanks,
Guido

The ticket I mentioned was created to encrypt any communication between Kuberneetes pods.If you had 2 instances of A12 services running this would still qualify.

I believe that we will need to take a look at our java clients and look for a way to encrypt the communication as well.

Again - this is only transport encryption and not content encryption. For content encryption, you will need to encrypt the payload before sending it over the wire, so even a man-in-the-middle attack would not work without the actual decryption key.