> 2 then each container sends its (pub) to tmaster and embeds all pub keys (N pub keys) in physical plan to all containers.
If this is transmitted over a non-secure channel, wouldn't there be a chance to tamper the keys? On Thu, Sep 14, 2017 at 5:12 PM FatJ Love <[email protected]> wrote: > 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? > >> > > > > > >> > > > > >> > > > >> > > >> > > > > > -- Matteo Merli <[email protected]>
