[
https://issues.apache.org/jira/browse/YARN-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15767884#comment-15767884
]
Varun Saxena edited comment on YARN-5647 at 12/21/16 7:11 PM:
--------------------------------------------------------------
bq. Something to think about and answer, however: how do we ensure we don't get
mixed up with the timeline state store from v.1 on the same node? Is it not a
concern because in v.1 the state store would be on the RM machine?
Different DB names should ward that off. I was planning to consider these
changes(i.e. recovery related changes) in another JIRA. For this JIRA, we can
assume that it's a fresh setup.
bq. there is the scenario of using a reader instance to access other clusters'
data than the one the reader belongs to. It's not clear how to
implement/enforce authentication for that.
Not sure if I understood it correctly. Do you mean how do we identify if a
request is originating from cluster1(say) and trying to access data of
cluster2(say) ?
It will be hard to identify what is cluster 1 and what is cluster 2 effectively
unless a list of hosts belonging to each is maintained, which I don't think is
a feasible solution.
I think this entirely depends on the way deployment is done and whether
isolation amongst clusters is required. Frankly, this issue is more about
authorization. And, can be achieved by having different users based on cluster
or apps or some other criteria. For instance, if we do not want users of one
cluster to access data of other we can probably have a different set of users
for both. It's not only about clusters, you may not want to have access to
applications as well.
Now, we can define ACLs' at the entity level and check against them while
returning results from the reader. And Kerberos authentication for each user
would anyways be done.
In ATSv1 we used to have multiple entities published within the scope of a
specific domain. We can probably extend the same idea when we implement
authorization. This anyways would require more thought and discussion and can
be done when we decide on the design for authorization.
Also, it may not be necessary for a reader to belong to a specific cluster(if
ownership for each cluster is different). If its that big a concern, you can
choose to have separate reader(s) for each cluster.
was (Author: varun_saxena):
bq. Something to think about and answer, however: how do we ensure we don't get
mixed up with the timeline state store from v.1 on the same node? Is it not a
concern because in v.1 the state store would be on the RM machine?
Different DB names should ward that off. I was planning to consider these
changes(i.e. recovery related changes) in another JIRA. For this JIRA, we can
assume that its a fresh setup.
bq. there is the scenario of using a reader instance to access other clusters'
data than the one the reader belongs to. It's not clear how to
implement/enforce authentication for that.
Not sure if I understood it correctly. Do you mean how do we identify if a
request is originating from cluster1(say) and trying to access data of
cluster2(say) ?
It will be hard to identify what is cluster 1 and what is cluster 2 effectively
unless a list of hosts belonging to each is maintained, which I dont think is a
feasible solution.
I think this entirely depends on the way deployment and whether isolation
amongst clusters is required. Frankly this issue is more about authorization.
And can be achieved by having different users based on cluster or apps or some
other criteria. For instance, if we do not want users of one cluster to access
data of other we can probably have different set of users for both. Its not
only about clusters, you may not want to have access across applications as
well.
Now, we can define ACLs' at entity level and check against them while returning
results from reader. And kerberos authentication for each user would anyways be
done.
In ATSv1 we used to have multiple entities published within the scope of a
specific domain. We can probably extend the same idea when we implement
authorization. This anyways would require more thought and discussion and can
be done when we decide on design for authorization.
Also, it may not be necessary for a reader to belong to a specific cluster(if
ownership for each cluster is different). If its that big a concern, you can
choose to have separate reader(s) for each cluster.
> [Security] Collector and reader side changes for loading auth filters and
> principals
> ------------------------------------------------------------------------------------
>
> Key: YARN-5647
> URL: https://issues.apache.org/jira/browse/YARN-5647
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: timelineserver
> Reporter: Varun Saxena
> Assignee: Varun Saxena
> Labels: yarn-5355-merge-blocker
> Attachments: YARN-5647-YARN-5355.wip.002.patch,
> YARN-5647-YARN-5355.wip.003.patch, YARN-5647-YARN-5355.wip.01.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
