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 >
