I had the same thought, but am curious if you've solved the following problems:
Would you bake the private key into the container or set it at runtime? If you set it at runtime how will two containers in different places know who to talk to?
Perhaps you generate the keys at build time and add the public keys to the partner containers, then at run time you inject the private key into the container via an env var. Now you have to securely manage and transport private keys and you've got two problems.
There must be other things I'm not considering.
And, of course, whatever system is running the container can step into it and read the private keys (or any malicious containers running on the host that are able to break out of the container). But we can just avoid that by saying they are our own hardware.
I was thinking that you could bake a the Snow keys of a centralized set of discovery servers that also happen to provide key transport into the containers (so, basically, something like SkyDNS). The containers would generate private keys at runtime and then advertise themselves with the discovery servers.
Would you bake the private key into the container or set it at runtime? If you set it at runtime how will two containers in different places know who to talk to?
Perhaps you generate the keys at build time and add the public keys to the partner containers, then at run time you inject the private key into the container via an env var. Now you have to securely manage and transport private keys and you've got two problems.
There must be other things I'm not considering.
And, of course, whatever system is running the container can step into it and read the private keys (or any malicious containers running on the host that are able to break out of the container). But we can just avoid that by saying they are our own hardware.