So I’m architecting a small system, where there will be 2 apps. One that is end-user facing only (public like app) and another that is admin only. The public one will be connected to a database containing pruned and cleaned up records while the admin one will be connected to both that database and another one. Now I would like that the admin app would be connected to the public facing one, able to use Erlang node comm, but not the other way around, so that the admin app could directly change state in the public one. This will be deployed in AWS EC2, I will open the node communication ports in the public one restricting the ip range to that of the admin one.
The reason for this is that the public facing app will contain views based on data from the pruned datasets, but the admins will be doing updates to the data monthly, so I want to re-use the views from the public facing app to output “previews” in the admin with data that hasn’t been yet persisted, to see if everything adds up correctly, this way preventing duplication of views. Does this seem like a reasonable idea? In my head it does.
If that is possible, how would I set up the cookies and node names and connect the admin app when it starts up?
The idea is that in case I end up with several public facing instances in the future, I would be able to retrieve their addresses registered in the loadbalancer and then automatically connect the admin to any N public apps.
Thanks for the reference - yes I can simply add some routes in the public facing app and lock them to only admins - but if it was easy to prevent one node from connecting to the other one/executing any calls on the other one that would be nicer (at least for me conceptually) and I would use the opportunity to learn more about this.
Regarding node comm, if I get it right, they’ll both need to have the same cookie which means they’ll need to be technically open to connections (although I can just not open the relevant ports in AWS for the admin one, that would be relying on a detail and not inbuilt). But this seems like a pretty common use case no? One node being able to access the runtime of another but not the other way around? Or am I just looking at it wrongly?
Normally there’s no need for a VM-level mechanism to enforce that, since you control what code runs on each node. If you want security even when a node is compromised, then you can’t use the built-in Erlang distribution. See: Can I write a patch to increase the security of the Erlang distribution?
It makes sense I think I was basically expecting the same kind of conceptual framework that goes on processes (ability to link, one sided, supervisors -> workers, or similarly to ets public reads with private writes) to also be applicable at the node level, but there are probably real differences on how this would play out. Basically toying with the idea of how to control an app from another besides the regular http endpoints or writing my custom sockets/receives and implementing security for them. Thanks.
