So absolutely on the optional part, we should give tools for people to use,
not force them to use them.
That said, how do you manage things now. So you have kerberos and SSO for
Web access, so when people connect to Zeppelin, they access a different
conf directory per user, so there is a different interpreter.json (similar
to how I have things setup). In this scenario, given my suggestion, I
would set a master key in the zeppelin conf, and still have the passwords
to individual data sources (within interpreter.json) be encrypted, but the
user would have no need to know what that password was, it was just a
secret in the conf dir which should be secured. This just help make so the
interpreter.json can be updated and viewed without having plain text
passwords available. I am guessing in your ENV all things run through the
SSO? If so, I am jealous you have better architects that I have :)
On Fri, Apr 8, 2016 at 2:16 PM, MUEDSAM, JOHAN <jm8...@att.com> wrote:
> 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"
> Date: Friday, April 8, 2016 at 7:23 AM
> To: "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> 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
>>
>
>
