For key distribution and management: 1 each container generate a key pair (pri, pub) when the container launches. 2 then each container sends its (pub) to tmaster and embeds all pub keys (N pub keys) in physical plan to all containers. 3 now each container has its own pri key and all pub key (one pri key and N pub keys)
On Thu, Sep 14, 2017 at 5:07 PM, FatJ Love <[email protected]> wrote: > 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? >> > > > > >> > > > >> > > >> > >> > >
