[
https://issues.apache.org/jira/browse/HADOOP-13081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15563221#comment-15563221
]
Sergey Shelukhin commented on HADOOP-13081:
-------------------------------------------
Sorry, I've posted this in the wrong JIRA apparently:
The scenario is like this; we accept work on behalf of clients that is,
generally speaking, authorized on a higher level (those are fragments of Hive
jobs right now, except unlike MR they all run in-process, and we are also
making the external client which is the crux of the matter). In normal case,
the service doing the auth (HiveServer2 in case of Hive) gathers the tokens and
passes them on to the service running the fragment; the external client may
supply some tokens too. However, apparently for some clients it's difficult (or
not implemented yet) to gather tokens, so in the cases of perimeter security,
we want to be able to configure access in such way that they can access all of
HDFS (for example; it could be some other service that their code touched that
we have no idea about, hypothetically). The reasoning is that if the work item
has passed thru the authorization that our service does, they don't care about
HDFS security any more. In that case, our service would log in from keytab and
run their item in that context. However, we neither want to require a
super-user that is able to access all possible services (e.g. HBase), nor
disable HDFS security altogether. So, the user work items would access HDFS (or
HBase or whatever) as a user with lots of access, by design, and access other
services via tokens.
This feature is off by default, obviously, and the of their code talking to
services is based entirely on tokens by default.
I understand running as such user is not an ideal situation but it is
apparently a valid scenario for some cases.
So, what we do now is create a master UGI/Subject; for every task, if this is
enabled, we clone that via reflection and add the tokens. We haven't
extensively tested this yet since external client is not production ready but
it appears to work in some tests.
I hope this makes sense, feel free to clarify.
We are using reflection to get the subject and construct the UGI from subject.
> add the ability to create multiple UGIs/subjects from one kerberos login
> ------------------------------------------------------------------------
>
> Key: HADOOP-13081
> URL: https://issues.apache.org/jira/browse/HADOOP-13081
> Project: Hadoop Common
> Issue Type: Improvement
> Components: security
> Reporter: Sergey Shelukhin
> Assignee: Sergey Shelukhin
> Fix For: 2.8.0, 3.0.0-alpha1
>
> Attachments: HADOOP-13081.01.patch, HADOOP-13081.02.patch,
> HADOOP-13081.02.patch, HADOOP-13081.03.patch, HADOOP-13081.03.patch,
> HADOOP-13081.patch
>
>
> We have a scenario where we log in with kerberos as a certain user for some
> tasks, but also want to add tokens to the resulting UGI that would be
> specific to each task. We don't want to authenticate with kerberos for every
> task.
> I am not sure how this can be accomplished with the existing UGI interface.
> Perhaps some clone method would be helpful, similar to createProxyUser minus
> the proxy stuff; or it could just relogin anew from ticket cache.
> getUGIFromTicketCache seems like the best option in existing code, but there
> doesn't appear to be a consistent way of handling ticket cache location - the
> above method, that I only see called in test, is using a config setting that
> is not used anywhere else, and the env variable for the location that is used
> in the main ticket cache related methods is not set uniformly on all paths -
> therefore, trying to find the correct ticket cache and passing it via the
> config setting to getUGIFromTicketCache seems even hackier than doing the
> clone via reflection ;) Moreover, getUGIFromTicketCache ignores the user
> parameter on the main path - it logs a warning for multiple principals and
> then logs in with first available.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
