heron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From FatJ Love <huijun.wu.2...@gmail.com>
Subject Re: Inter-Container Encryption in Heron
Date Fri, 15 Sep 2017 00:07:12 GMT
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?
> > > > >
> > > >
> > >
> >
>

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