Fork me on GitHub
Ivar Refsdal13:08:19

Hi. We're deploying to azure container instances inside a private virtual network. We have access to the virtual network via VPN/sshuttle. Should my embedded nREPL server simply bind to - or should a more secure approach be used? How if so? Or is it fine to bind to in a private network? I don't like the thought of having the server bind to should it one day be exposed publicly by accident.


But the bind happens inside the container, right? And you have to expose a known port number to access it?


So the only risk is that the nrepl would be exposed to containers on the same bridge network, not to the outside world

Ivar Refsdal13:08:19

That's correct. I suppose I should settle for simplying binding to

Ivar Refsdal13:08:20

This is - uh - azure land for lack of a better phrasing. The setup is such that one graphql server is exposed publicly and this service talks to "underlying" services (on the same subnet). Not sure if that answers your questions Cora? Re security and nREPL: I figured one option would be to add TLS support to nREPL server. That would be a good solution. Then I'd have to manage certs/keys, etc.. There is less-awful-ssl by aphyr which one could look at to implement such a solution. Edit: Link to less-awful-ssl:

Ivar Refsdal14:08:36

Yes, it's only a container. I tried to use apache mina sshd (and it worked), but I suspect that it conflicted with yada/aleph/netty/datomic somehow. I could be wrong about that though.


If you're worried about accidental exposure you could add a network security group to the ACI subnet that only allows traffic to the nREPL port if it originates from the same vnet

👍 3