I am not a cryptographer. There's probably a fatal mistake in my post. (Do let me know if you've spotted it! I've found & fixed a couple but you know what that say, anyone can come up with a cryptosystem they can't break, and I can barely break a Caesar cipher.)
You'll need to cheat somehow and give the service either entropy or a keypair out of band. You can't bootstrap your entropy from absolutely nothing via a remote service, unless you trust the adversary can't compromise the connection between the foo service & the camera service (which is equivalent to the foo service having a good local entropy source to begin with, it's just that part of your motherboard's bus extends over Ethernet to the camera service).
The simplest way would be for the foo and camera services to have keypairs, which you exchange manually/out of band, & communicate with classic asymmetric key cryptography. (You could come up with a similar protocol using symmetric encryption as well, using something like AES-GCM combined with a challenge-response protocol. You could also bootstrap the foo service with entropy out of band & use Diffie-Hellman to establish a shared key rather than moving keys out of band. Probably the better option in practice since there's less coupling. [Actually this doesn't quite work because it doesn't achieve authentication.])
The important part is that it's both authenticated and encrypted. You need to encrypt it so that adversaries tapping your connection don't know what image you're using to seed your CSPRNG. But if you allow unauthenticated connections to your entropy service, they don't need to tap your connection, they'll just connect to the camera service at the same time & pull down the same image that you do. And if they can't get it perfectly at the same time, well, a known image of a lava lamp taken around the same time as a secret image of a lava lamp gives us a lot of information about the state of that lava lamp, and we could conduct a search to discover the secret image (we record the encrypted traffic, and we fiddle with the image, and attempt to decrypt the traffic. When we get valid data instead of gibberish, we've found the right image.)
Let's say we've done all that. Great, we can actually lose the authentication requirement now. We can create an entropy service which does all of this song and dance, and seeds a CSPRNG. The entropy service accepts a public key, uses a CSPRNG to generate some entropy, encrypts it with the public key, and returns the result. Only the client is able to use their private key to retrieve the entropy. Because we've moved away from a camera system, past outputs are no longer correlated with future outputs, and concurrent requests always get different outputs. So we can leave this service unsecured. It's dependent services still need to be bootstrapped with a keypair out of band, however.