do you plan to use one key-pair for all the contaienrs or each container has one-key-pair?
On Thu, Sep 14, 2017 at 3:39 PM, Sanjeev Kulkarni <[email protected]> wrote: > 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 <[email protected]> > 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 <[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? > > > > > >
