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.