Re: Inter-Container Encryption in Heron

[Sanjeev Kulkarni <sa...@gmail.com>]

Hi all,
Just dusting this off now that the Strata mad rush is over :)
As I see it in the general design, there are certain things to design for
1. Some sort of encryption.yaml that controls whether we turn on encryption
and what level of checks we need to do.
2. At submit time a way to take in certificates. It seems atleast initially
we would want one certificate per topology rather than one per container.
3. A mechanism to upload these to a secure vault while submitting
4. A mechanism to download these from the secure vault to a specific place
when a container comes up
5. Pass on the arguments to relevant processes(stmgr mostly) of these
certificates.

For AJ and Brian, 3 will be NoOp uploader. 4 will be essentially some sort
of copy/link downloader that just symlinks the existing certs to a specific
location. I can come up with some specs for encryption.yaml based on
initial requirements. Am a little unsure about how to go about 2, but maybe
others have ideas or we can leave it out at the moment.
Thoughts?


On Mon, Sep 18, 2017 at 2:34 PM, FatJ Love <hu...@gmail.com> wrote:

> 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 <bm...@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 <sa...@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?
> > >
> >
>