heron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matteo Merli <mme...@apache.org>
Subject Re: Inter-Container Encryption in Heron
Date Fri, 15 Sep 2017 00:17:04 GMT
> 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 <huijun.wu.2010@gmail.com> 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 <huijun.wu.2010@gmail.com>
> 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 <sanjeevrk@gmail.com>
> > 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 <huijun.wu.2010@gmail.com>
> >> 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 <
> sanjeevrk@gmail.com>
> >> > 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 <
> karthik@streaml.io
> >> >
> >> > > 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 <
> >> sanjeevrk@gmail.com
> >> > >
> >> > > > 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
<mmerli@apache.org>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message