Hi Joel/Alex, Thanks for explaining the use case with multi tenant cluster.
@Joel Unfortunately I have not used the setup described above but from explanation looks like the impersonation tickets will be used by Drillbit's on Tenant A to restrict the MapR platform access by a limited set of Drillbit authenticated user. Using this any user in Tenant B will not be able to execute query on Tenant A even though it can be authenticated successfully by the Drillbit in Tenant A. This way authorization check is done at data layer. @Alex, Adding an authorization check for a valid authenticated cluster user shouldn't be a big change. Based on a configured set's of users/group a subset of cluster user can be allowed to connect. But can you please point to how other services do these authorization checks when running in multi tenant environment ? Based on my understanding all these authorization check in Hadoop system are done at data layer or they have a separate security service which does these checks along with other security checks for authentication, etc. Also please feel free to open a JIRA ticket with details. Thanks, Sorabh On Fri, Aug 17, 2018 at 11:21 AM, Oleksandr Kalinin <alexk...@gmail.com> wrote: > Hi Sorabh, > > Thanks for you comments. Joel described in detail our current thinking on > how to overcome the issue. We are not yet 100% sure if it will actually > work though. > > Actually I raised this topic in this mailing list because I think it's not > only specific to our setup. It's more about having nice "Drill on YARN" > feature with very limited (frankly, no) access control which almost makes > the feature unusable in environments where it is attractive - multi tenant > secure clusters. Supported security mechanisms are good for authentication, > but using them for authorization seems suboptimal. Typically, YARN clusters > run in single Kerberos realm and the need to introduce multiple realms and > separate identities for Drill service is not at all convenient (I am pretty > sure that in many environments like ours it is a no go). And how about use > cases with no Kerberos setup? If we can workaround access control by > MapR-specific security tickets like described by Joel - good for us, but > what about other environments? > > So the question is more whether it make sense to consider introducing user > authorization feature. This thread refers only to session authorization to > complement YARN feature, but it could be extendable of course, e.g. in > similar ways like Drill already supports multiple authentication > mechanisms. > > Thanks & Best Regards, > Alex > > On Wed, Aug 15, 2018 at 11:30 PM, Sorabh Hamirwasia <shamirwa...@mapr.com> > 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 <alexk...@gmail.com> > > 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 > > > > > >
