heron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjeev Kulkarni <sanjee...@gmail.com>
Subject Re: Inter-Container Encryption in Heron
Date Thu, 14 Sep 2017 22:39:35 GMT
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