heron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matteo Merli <matteo.me...@gmail.com>
Subject Re: Inter-Container Encryption in Heron
Date Fri, 15 Sep 2017 02:23:22 GMT
On Thu, Sep 14, 2017 at 5:26 PM FatJ Love <huijun.wu.2010@gmail.com> wrote:

> 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
>

That's correct but it might allow some other party to connect. E.g.  I
submit a modified public key and then I might be able to connect to other
bolts and send tuples.

Another option is that by spoofing the container IP one can impersonate it
(with the tampered public key) and receive tuples.


>
> On Thu, Sep 14, 2017 at 5:17 PM, Matteo Merli <mmerli@apache.org> 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 <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>
> >
>
-- 
Matteo Merli
<mmerli@apache.org>

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