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
