Hello, After discussing this topic with Alex, this is what we are trying to do. We are using MapR, with different tenants for different functional teams, each of these being represented by a dedicated LDAP group. We are planning to deploy Drill on Yarn, so that each group can deploy its own drill cluster, that will take resources from their own tenant's resources.
So there will be a User Group A launching a Drill cluster A running on a tenant A. And a User Group B launching a Drill cluster B running on a tenant B. We plan to use impersonation, so that Drill cannot be used to read data that the user account is not allowed to access. With the way the authentication works, nothing will prevent users from the group A to run queries on the Drill cluster deployed on the tenant B. Since the user from the group A will have a valid authentication, the Drill cluster B will happily process the query. So while this setup does prevent privilege escalation, it does not prevent one group from stealing resources from another group. As a work-around, we plan to use service with impersonation tickets, with restricted groups. So that the Drill cluster running on the tenant A, can only ever support the impersonation to the group A. Is it a supported setup, are you aware of anyone using this kind of setup? Regards, Joel On Wed, Aug 15, 2018 at 11:30 PM Sorabh Hamirwasia <[email protected]> wrote: > Hi Oleksandr, > Drill doesn't do any user management in itself, instead relies on the > corresponding security mechanisms in use to do it. It uses SASL framework > to allow using different pluggable security mechanisms. So it should be > upon the security mechanism in use to do the authorization level checks. > For example in your use case if you want to allow only certain set's of > users to connect to a cluster then you can choose to use Kerberos with each > cluster running in different realms. This will ensure client users running > in corresponding realm can only connect to cluster running in that realm. > > For the impersonation issue I think it's a configuration issue and the > behavior is expected where all queries whether from user A or B are > executed as admin users. > > Thanks, > Sorabh > > On Mon, Aug 13, 2018 at 9:02 AM, Oleksandr Kalinin <[email protected]> > wrote: > > > Hello Drill community, > > > > In multi-tenant YARN clusters, running multiple Drill-on-YARN clusters > > seems as attractive feature as it enables leveraging on YARN mechanisms > of > > resource management and isolation. However, there seems to be simple > access > > restriction issue. Assume : > > > > - Cluster A launched by user X > > - Cluster B launched by user Y > > > > Both users X and Y will be able to connect and run queries against > clusters > > A and B (in fact, that applies to any positively authenticated user, not > > only X and Y). Whereas we obviously would like to ensure exclusive usage > of > > clusters by their owners - who are owners of respective YARN resources. > In > > case users X and Y are non-privileged DFS users and impersonation is not > > enabled, then user A has access to data on behalf of user B and vice > versa > > which is additional potential security issue. > > > > I was looking for possibilities to control connect authorization, but > > couldn't find anything related yet. Do I miss something maybe? Are there > > any other considerations, perhaps this point was already discussed > before? > > > > It could be possible to tweak PAM setup to trigger authentication failure > > for "undesired" users but that looks like an overkill in terms of > > complexity. > > > > From user perspective, basic ACL configuration with users and groups > > authorized to connect to Drillbit would already be sufficient IMO. Or > > configuration switch to ensure that only owner user is authorized to > > connect. > > > > Best Regards, > > Alex > > >
