heron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Hatfield <bmhatfi...@gmail.com>
Subject Re: Inter-Container Encryption in Heron
Date Mon, 18 Sep 2017 20:59:47 GMT
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