I think I know the problem but I am guessing.
When YARN jobs are launched the MapR client runtime in YARN authenticates to
the RM using the current ticket. That results in the YARN RM knowing you are
"foo' in this case. When the actual containers are launched they are started
with a freshly gen
Hi Keys,
Thanks for your reply. Neither I want to make this conversation specific to
environment/vendor, so ready to go off the list any time as soon as anyone
signals.
Thanks for clarifying item (2).
For item (1) yes we did check ticket contents with maprlogin print, it is
correct (listing UID
Alex,
Obviously I don't want this conversation to sound too much like a vendor
conversation but I do want to be helpful. If folks think this is too vendor
specific I'm happy to take the conversation off list but others that are using
Drill on MapR might benefit here as well.
This is helpful. L
Hi Keys,
Assume we want to :
- Run Drill cluster on YARN as user 'foo' (UID = N)
- Authorize all users in group 'bar' (GID = K) for running Drill queries on
that cluster with impersonation enabled
- All other users should be able to connect to the cluster, but their
queries should fail with impers
Can you comment on what isn't working with MapR in this scenario? I'm familiar
with impersonation tickets and constrained impersonation.
That said, I do agree that a general purpose feature in Drill that allows one
to constrain who can issue queries seems useful.
Keys
__
Hello,
"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
Hi Sorabh,
In case of Hive, user connects to Hive server. Launching the query launches
YARN application - each query is YARN application. To make sure that query
uses YARN cluster resources launching user is authorized to use, YARN
authorization kicks in - e.g. YARN queue ACLs - mechanism a bit si
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
Drillb
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 n
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
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 chec
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
12 matches
Mail list logo
