I like the idea of a “user configuration” directory that is separate from the overall application directory . Right now I have to replicate the entire conf directory for each user when all I’m trying to accomplish is to have the interpreter.json file writable per user.
When it comes to password storage that would not be allowed in our environment, we use kerberos for cluster access and SSO for web access so please keep it optional as you mention in your post. From: John Omernik Reply-To: "users@zeppelin.incubator.apache.org<mailto:users@zeppelin.incubator.apache.org>" Date: Friday, April 8, 2016 at 7:23 AM To: "users@zeppelin.incubator.apache.org<mailto:users@zeppelin.incubator.apache.org>" Subject: Re: Storing Interpreter Passwords As a follow up on a computer rather than iPad :) One thing I want to be clean on, Zeppelin would NOT store this encryption password. Obviously this would be optional, as many users would not want to use it (I have to enter ANOTHER password? !?!?!) however it could be an option. Another option that would be transparent to the user and rely on secured installation of Zeppelin could work like this. 1. A new directory is created strictly for intepreter.json files, let's call this $INTERPRETER_CONF. 2. As stated before, interpreter.json should be per user. They are stored in $INTERPRETER_CONF/${USER}_interpreter.json. If User Auth is NOT setup, then there is only one, perhaps interpreter.json which can also be used as a template for any interpreter settings that ARE shared. 3. In the Zeppelin config file, a "master key" is stored. This is optional, if users don't have to enter password at each session, then use a master key. 4. Master conf location is locked down. SInce the master key is here, only the directory is chown to the user/primary gid of the user running Zeppelin. the Directory is set 770 and the files 660. This way the key is relatively secure from wandering eyes. 5. The interpreter conf is not locked down. This way, users can edit the files as needed. (Perhaps a process to updated interpreters "outside" of Zeppelin running as the user). However, the passwords stored in this file are encrypted to a symmetric key. Thus if a user reads it, they don't know their actual database credentials. Only the Zeppelin user knows this. 6. As stated in 3. The option to force each user, per session to enter a key for higher security is available. However, just using a master key in the conf file will make the interpreter.json files more secure as there will not be plain text passwords stored there. Different keys will not be a problem, if a master key is not specified, then Zeppelin will read the value from the interpreter file, if the connection fails, then Zeppelin can prompt for a session level key. This will allow for hybrid installations where a group of users use the master key, and then high security users specify their own keys at new session. The session keys don't have to be managed by Zeppelin, as it is only symmetric encryption to the value in the file, (not the whole file). If the password provided by the user is correct, the DB connection will succeed, if it fails, and the user forgot their password, then Zeppelin provides an option to specify a new password to the data, with the option to use the master key for encryption (if exists) or provide new key for high security users. The goal here is not to solve all security problems and make this perfect, its to take a number of obvious audit items that orgs may have (plain text passwords, lack of accountability of access to data stores, etc) and provide some options to handle that. By default, no passwords are needed, and if security is not a concern, there is no issue, but with the multiple interpreter files per user, and then an option for master key, or per user keys to encrypt secrets in the interpreter.json files, along with securing the zeppelin_conf directory, I think there is a strong case that the audit requirements can be met. Note, in addition to all this, I would love an option in the UI to "hide" values on a per cell basis for password field. Independent of all the above, just having my password in plain text on my screen really makes nervous :) If we could just tick a "hide value" check box by ever value, with a default of visible, it would be handy. John On Thu, Apr 7, 2016 at 8:32 PM, John Omernik <j...@omernik.com<mailto:j...@omernik.com>> wrote: Ah good point. One way could be to use asymmetric keys instead of symmetric encryption. An example is how you can encrypt an email to multiple recipient's public keys, however that does create complexity. I think from an enterprise standpoint, good security practices discourage shared passwords, and that's what a shared interpreter.json ends up being. What if when multiuser is enabled, each person gets their own interpreter.json. If shared passwords are used, they are just written to each individuals interpreter.json. Basically, it gives each user the ability to manage their own interpreter settings. On Thursday, April 7, 2016, moon soo Lee <m...@apache.org<mailto:m...@apache.org>> wrote: 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 -- Sent from my iThing
