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 Mon, 18 Sep 2017 21:34:43 GMT
If I understand correctly, Brian was suggesting:
adding 3 params `certificate` `key` `trust store/CA`  to launch
heron-executor



On Mon, Sep 18, 2017 at 1:59 PM, Brian Hatfield <bmhatfield@gmail.com>
wrote:

> Hey there.
>
> I believe that AJ and I are are the "at least one current user of Heron"
> you're referring to, so we thought we'd weigh in on this conversation:
>
> *Cert/Key Distribution:*
> For key distribution, we request that Heron accept as a set of arguments
> the file paths where the components will load the cert/key/trust from once
> deployed. We'll manage the actual key material separately from Heron.
>
> Why? Because we already have our own PKI and we want to use it. Accepting a
> path (well, three paths: certificate, key, trust store) allows us maximum
> flexibility in how we distribute or provision these credentials. Some
> people may want to use a unique certificate per topology (distributed in
> the sandbox, eg), others will be satisfied with one certificate per
> machine, others may just use one everywhere - this choice should be up to
> the user. I think engineering for a unique key per container is unnecessary
> at this time.
>
>
> *Certificate Use:*
> We'd like to be able to set up TLS mutual auth ("client" and "server"
> components each present a cert/key and validate it). We'd also like to use
> a proper PKI with signed certificates and a trust hierarchy - meaning that
> the component verifying the connection will need to know which
> intermediate/root certificates we'd like to present and use (aka the trust
> store mentioned above). This should be optional as many folks won't want to
> do mutual auth.
>
> The authenticity of the certificates should be validated - signed by a
> trusted CA (or self-signed and trusted that way), not expired, etc. We'd
> also like the TLS ciphers and protocol that are used to be configurable.
>
> I hope that helps,
> Brian
>
>
> On Thu, Sep 14, 2017 at 6: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