Assume there are 2 containers A and B --- case 1, only one key (pub, pri) for container A and container B 1. contaienr A sends packet to container B container A enc packet with key pub container B dec packet with key pri. 2. contaienr B sends packet to container A container B enc packet with key pub container A dec packet with key pri. Both A and B have same (pub, pri), why not use symmetric key ?
--case 2, container A has (pubA, priA). container B has (pubB, priB) 1 contaienr A sends packet to container B container A enc packet with key pubB container B dec packet with key priB. 2 contaienr B sends packet to container A container B enc packet with key pubA container A dec packet with key priA. The packet is encrypted. ---case 3, same assumption with case2 1 contaienr A sends packet to container B container A enc packet with key priA container B dec packet with key pubA. 2 contaienr B sends packet to container A container B enc packet with key priB container A dec packet with key pubB. container A authenticates B and B can authenticate A as well. ---case 4, combine case 2 and case3 both encrytion and authentication On Thu, Sep 14, 2017 at 4:34 PM, Sanjeev Kulkarni <[email protected]> wrote: > At this point, the thought is towards having one key pair accross the > entire topology. I'm not sure one key pair per container will add that much > more security. Thoughts? > > On Thu, Sep 14, 2017 at 4:30 PM, FatJ Love <[email protected]> > wrote: > > > do you plan to use one key-pair for all the contaienrs or > > each container has one-key-pair? > > > > On Thu, Sep 14, 2017 at 3:39 PM, Sanjeev Kulkarni <[email protected]> > > wrote: > > > > > The keys ideally should be different for every topology. And ideally > they > > > should be created in a just in time manner while launching the > topology. > > > Otherwise, the chance that keys are no longer secret increases. > > > > > > > > > On Thu, Sep 14, 2017 at 3:34 PM, Karthik Ramasamy <[email protected]> > > > wrote: > > > > > > > Another option is keep this configuration in heron cli. For example, > > > > > > > > heron config <cluster> set --private-key "...." > > > > heron config <cluster> set --publick-key "...." > > > > > > > > Once the user sets it, then we can use these keys? > > > > > > > > cheers > > > > /karthik > > > > > > > > On Thu, Sep 14, 2017 at 3:11 PM, Sanjeev Kulkarni < > [email protected] > > > > > > > wrote: > > > > > > > > > Hi all, > > > > > I believe at-least one current user of Heron is interested in > > > encrypting > > > > > their inter-container data flow within a Heron topology. Since > > > > > inter-container traffic is between stmgrs, and because stmgrs use > > > > libevent > > > > > bufferevents for their transport, adding ssl in transport layer > > between > > > > > stmgrs is fairly straightforward. > > > > > The bigger question is how credentials are > > managed/transferred/stored. > > > > One > > > > > approach would to pass the public/private key as an argument to the > > > heron > > > > > cli while submitting the job. These will be stored in the uploader > > > > > alongside topology jars and downloaded by the containers upon > start. > > > The > > > > > one issue with this approach is that the keys need to be secured by > > the > > > > > uploader. > > > > > I believe Kubernetes has provision for keeping secrets for jobs, > but > > it > > > > > might not be portable to other scheduler environments. A way around > > > this > > > > > would be to create an spi for keeping secrets in heron/spi, but not > > > sure > > > > > what others feel about this. > > > > > Any other ideas? > > > > > > > > > > > > > > >
