The pri keys never appear on network. The pub keys are transfered over network. Pub keys are supposed to be public. If pub key is changed , it cannot match the pri key stored in container
On Thu, Sep 14, 2017 at 5:17 PM, Matteo Merli <[email protected]> wrote: > > 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]> >
