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> 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> 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
>
