Hi, Thanks for starting this discussion and sharing your idea.
I open Zeppelin, then I get a a little lock icon showing me that my > passwords (and thus passwords in JDBC or other storage plugins are not > available) I click on the lock, and then I can enter in a password for the > session. That password can be used for symmetric encryption of the values > stored in the interpreter.json file... thus if the files are accessed, they > are encrypted One question is, multiple different user can login into Zeppelin since Zeppelin support authentication and authorization. So, if password from single user is being used to encrypt interpreter.json, other users might not able to read it. That means only single user can have access to the interpreters. Do you have any thoughts how encryption of interpreter.json can work with multiple users? Thanks, moon On Fri, Apr 8, 2016 at 9:21 AM John Omernik <j...@omernik.com> wrote: > Any thoughts on this? Since almost every interpreter could have a > password, the interpreter.json file is a huge security target. If we > stored the passwords in the interpreter.json file, then in the notebook > interface had an option to provide the "unlock" password, and before > running one of the interpreters we could force an unlock, this seems to > provide somewhat better security than just storing them in plain test. I > am interested in discussions here, perhaps some philosophy on what should > fall on Zeppelin to secure and what should not. > > On Wednesday, April 6, 2016, John Omernik <j...@omernik.com> wrote: > >> Is there any good guidance for storing interpreter passwords? While I >> know it likely has to be in the interpreter.json files as plain text, is >> there something more we could do? Perhaps store encrypted to a master >> password that the user, once they are in Zeppelin can. >> >> (I.e, I open Zeppelin, then I get a a little lock icon showing me that my >> passwords (and thus passwords in JDBC or other storage plugins are not >> available) I click on the lock, and then I can enter in a password for the >> session. That password can be used for symmetric encryption of the values >> stored in the interpreter.json file... thus if the files are accessed, they >> are encrypted. ) >> >> At the very least, I would really ask that as we enter passwords in the >> UI for interpreters, that we mask the password fields (or provide an option >> by every field to mask if needed... perhaps giving interpreter writers the >> options to auto mask certain default options? >> >> I think this would be a good discussion to have because we should be >> considering security in the context of what data a user has access to, if >> Zeppelins configuration leaks information that's not a good thing. >> >> John >> >> >> >> > > -- > Sent from my iThing >
