You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@drill.apache.org by Vitalii Diravka <vi...@apache.org> on 2021/01/20 23:33:28 UTC
[DISCUSSION] Roles and Privileges, Security, Secrets
Hi Dev and User,
Drill has a very important feature - Roles and Privileges [1], but it has
really weak functionality. There are only two roles (admin and user) and
admin can't really give any user permissions to set query options for all
their sessions or to allow configure storage plugin in other manner, etc.
I think it is necessary to make this functionality broader: introduce a
middle layer user-system options, the ability to change some configs of
Storage Plugins for users, possibly permission for UDF creation etc. The
main thing that this functionality requires good support for management of
users and their secrets (credentials).
There is a very good tool - Hashicorp Vault [2], which can provide Drill a
mechanism to store secrets in a safe manner, to deliver the secrets via
tokens mechanism to the proper users and it can be integrated with Kerberos
and Spnego.
What do you think? Can we integrate Drill with Vault or no, what additional
pros and cons of this decision? If it is a good decision I can start
preparing design for this functionality
[1] https://drill.apache.org/docs/roles-and-privileges/
[2] https://www.vaultproject.io/
Kind regards
Vitalii
Re: [DISCUSSION] Roles and Privileges, Security, Secrets
Posted by Charles Givre <cg...@gmail.com>.
I think the issue that started this whole thread is that the non-file based storage plugins. Consider the following situation: You have users A and B who want to access an RDBMS via Drill. As currently implemented, we have a few options:
1. Admin supplies a global credential for Drill users (which is actually visible to users A and B). The obvious disadvantage to this approach is that it is not possible to audit the queries and determine who (between user A or B) is accessing the database. Likewise, if users A and B had different access roles, it would not be possible to control access.
2. Create separate RDBMS instances for Users A and B. The issue here, is that user A would still be able to query user B's instance and their credentials would possibly be visible to each other.
The other issue at play here is that whichever approach is taken, these creds are still stored in plain text.
Best
-- C
> On Jan 21, 2021, at 7:21 AM, Vitalii Diravka <vi...@apache.org> wrote:
>
> The goal to improve Identity, Authentication, Authorization in Drill.
> The specific cases are to manage Drill users and their permissions better,
> to give them ability to add/edit some Storage Plugin configs, to set System
> options for itself only.
> And possibly some separate UI page can be added for admin for that purpose.
> Also improving some gaps should be done, for instance storing user/pass in
> plain text in plugin configs.
>
> I agree about complexity magnified around the kerberos. Possibly
> implementing the separate security mechanism can be considered.
> I just know that Vault can work with kerberos, so looks like it should be
> easier to integrate it to Drill. And any Drill
> *Identity, Authentication, Authorization* functionality can be built with
> this tool too.
> I'll investigate SPIFFE with (or instead of) Vault:
> https://spiffe.io/docs/latest/spire/understand/comparisons/
>
>
> Kind regards
> Vitalii
>
>
> On Thu, Jan 21, 2021 at 2:39 AM Ted Dunning <te...@gmail.com> wrote:
>
>> I think that pushing too much of this kind of authentication and
>> authorization logic into Drill has a large complexity risk. Anything to do
>> with kerberos magnifies that complexity.
>>
>> I also think that it is a mistake to depend on user identity if
>> authorization tokens are likely to need to be embedded in scripts and such.
>> Identity that is inherited can work that way, but identity that has to be
>> given to a script should use an alternative intended for workload
>> authorization such as SPIFFE.
>>
>> Is there a reason that most or all of this couldn't be handled by storing
>> the configuration in files? That would allow file permissions to naturally
>> allow or disallow these operations.
>>
>> Also, what are the specific goals here?
>>
>>
>>
>> On Wed, Jan 20, 2021 at 3:34 PM Vitalii Diravka <vi...@apache.org>
>> wrote:
>>
>>> Hi Dev and User,
>>>
>>> Drill has a very important feature - Roles and Privileges [1], but it has
>>> really weak functionality. There are only two roles (admin and user) and
>>> admin can't really give any user permissions to set query options for all
>>> their sessions or to allow configure storage plugin in other manner, etc.
>>>
>>> I think it is necessary to make this functionality broader: introduce a
>>> middle layer user-system options, the ability to change some configs of
>>> Storage Plugins for users, possibly permission for UDF creation etc. The
>>> main thing that this functionality requires good support for management
>> of
>>> users and their secrets (credentials).
>>>
>>> There is a very good tool - Hashicorp Vault [2], which can provide
>> Drill a
>>> mechanism to store secrets in a safe manner, to deliver the secrets via
>>> tokens mechanism to the proper users and it can be integrated with
>> Kerberos
>>> and Spnego.
>>>
>>> What do you think? Can we integrate Drill with Vault or no, what
>> additional
>>> pros and cons of this decision? If it is a good decision I can start
>>> preparing design for this functionality
>>>
>>>
>>> [1] https://drill.apache.org/docs/roles-and-privileges/
>>> [2] https://www.vaultproject.io/
>>>
>>> Kind regards
>>> Vitalii
>>>
>>
Re: [DISCUSSION] Roles and Privileges, Security, Secrets
Posted by Vitalii Diravka <vi...@apache.org>.
The goal to improve Identity, Authentication, Authorization in Drill.
The specific cases are to manage Drill users and their permissions better,
to give them ability to add/edit some Storage Plugin configs, to set System
options for itself only.
And possibly some separate UI page can be added for admin for that purpose.
Also improving some gaps should be done, for instance storing user/pass in
plain text in plugin configs.
I agree about complexity magnified around the kerberos. Possibly
implementing the separate security mechanism can be considered.
I just know that Vault can work with kerberos, so looks like it should be
easier to integrate it to Drill. And any Drill
*Identity, Authentication, Authorization* functionality can be built with
this tool too.
I'll investigate SPIFFE with (or instead of) Vault:
https://spiffe.io/docs/latest/spire/understand/comparisons/
Kind regards
Vitalii
On Thu, Jan 21, 2021 at 2:39 AM Ted Dunning <te...@gmail.com> wrote:
> I think that pushing too much of this kind of authentication and
> authorization logic into Drill has a large complexity risk. Anything to do
> with kerberos magnifies that complexity.
>
> I also think that it is a mistake to depend on user identity if
> authorization tokens are likely to need to be embedded in scripts and such.
> Identity that is inherited can work that way, but identity that has to be
> given to a script should use an alternative intended for workload
> authorization such as SPIFFE.
>
> Is there a reason that most or all of this couldn't be handled by storing
> the configuration in files? That would allow file permissions to naturally
> allow or disallow these operations.
>
> Also, what are the specific goals here?
>
>
>
> On Wed, Jan 20, 2021 at 3:34 PM Vitalii Diravka <vi...@apache.org>
> wrote:
>
> > Hi Dev and User,
> >
> > Drill has a very important feature - Roles and Privileges [1], but it has
> > really weak functionality. There are only two roles (admin and user) and
> > admin can't really give any user permissions to set query options for all
> > their sessions or to allow configure storage plugin in other manner, etc.
> >
> > I think it is necessary to make this functionality broader: introduce a
> > middle layer user-system options, the ability to change some configs of
> > Storage Plugins for users, possibly permission for UDF creation etc. The
> > main thing that this functionality requires good support for management
> of
> > users and their secrets (credentials).
> >
> > There is a very good tool - Hashicorp Vault [2], which can provide
> Drill a
> > mechanism to store secrets in a safe manner, to deliver the secrets via
> > tokens mechanism to the proper users and it can be integrated with
> Kerberos
> > and Spnego.
> >
> > What do you think? Can we integrate Drill with Vault or no, what
> additional
> > pros and cons of this decision? If it is a good decision I can start
> > preparing design for this functionality
> >
> >
> > [1] https://drill.apache.org/docs/roles-and-privileges/
> > [2] https://www.vaultproject.io/
> >
> > Kind regards
> > Vitalii
> >
>
Re: [DISCUSSION] Roles and Privileges, Security, Secrets
Posted by Ted Dunning <te...@gmail.com>.
I think that pushing too much of this kind of authentication and
authorization logic into Drill has a large complexity risk. Anything to do
with kerberos magnifies that complexity.
I also think that it is a mistake to depend on user identity if
authorization tokens are likely to need to be embedded in scripts and such.
Identity that is inherited can work that way, but identity that has to be
given to a script should use an alternative intended for workload
authorization such as SPIFFE.
Is there a reason that most or all of this couldn't be handled by storing
the configuration in files? That would allow file permissions to naturally
allow or disallow these operations.
Also, what are the specific goals here?
On Wed, Jan 20, 2021 at 3:34 PM Vitalii Diravka <vi...@apache.org> wrote:
> Hi Dev and User,
>
> Drill has a very important feature - Roles and Privileges [1], but it has
> really weak functionality. There are only two roles (admin and user) and
> admin can't really give any user permissions to set query options for all
> their sessions or to allow configure storage plugin in other manner, etc.
>
> I think it is necessary to make this functionality broader: introduce a
> middle layer user-system options, the ability to change some configs of
> Storage Plugins for users, possibly permission for UDF creation etc. The
> main thing that this functionality requires good support for management of
> users and their secrets (credentials).
>
> There is a very good tool - Hashicorp Vault [2], which can provide Drill a
> mechanism to store secrets in a safe manner, to deliver the secrets via
> tokens mechanism to the proper users and it can be integrated with Kerberos
> and Spnego.
>
> What do you think? Can we integrate Drill with Vault or no, what additional
> pros and cons of this decision? If it is a good decision I can start
> preparing design for this functionality
>
>
> [1] https://drill.apache.org/docs/roles-and-privileges/
> [2] https://www.vaultproject.io/
>
> Kind regards
> Vitalii
>
Re: [DISCUSSION] Roles and Privileges, Security, Secrets
Posted by Ted Dunning <te...@gmail.com>.
I think that pushing too much of this kind of authentication and
authorization logic into Drill has a large complexity risk. Anything to do
with kerberos magnifies that complexity.
I also think that it is a mistake to depend on user identity if
authorization tokens are likely to need to be embedded in scripts and such.
Identity that is inherited can work that way, but identity that has to be
given to a script should use an alternative intended for workload
authorization such as SPIFFE.
Is there a reason that most or all of this couldn't be handled by storing
the configuration in files? That would allow file permissions to naturally
allow or disallow these operations.
Also, what are the specific goals here?
On Wed, Jan 20, 2021 at 3:34 PM Vitalii Diravka <vi...@apache.org> wrote:
> Hi Dev and User,
>
> Drill has a very important feature - Roles and Privileges [1], but it has
> really weak functionality. There are only two roles (admin and user) and
> admin can't really give any user permissions to set query options for all
> their sessions or to allow configure storage plugin in other manner, etc.
>
> I think it is necessary to make this functionality broader: introduce a
> middle layer user-system options, the ability to change some configs of
> Storage Plugins for users, possibly permission for UDF creation etc. The
> main thing that this functionality requires good support for management of
> users and their secrets (credentials).
>
> There is a very good tool - Hashicorp Vault [2], which can provide Drill a
> mechanism to store secrets in a safe manner, to deliver the secrets via
> tokens mechanism to the proper users and it can be integrated with Kerberos
> and Spnego.
>
> What do you think? Can we integrate Drill with Vault or no, what additional
> pros and cons of this decision? If it is a good decision I can start
> preparing design for this functionality
>
>
> [1] https://drill.apache.org/docs/roles-and-privileges/
> [2] https://www.vaultproject.io/
>
> Kind regards
> Vitalii
>