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 <[email protected]> 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 <[email protected]> > 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? > > >
