[
https://issues.apache.org/jira/browse/YARN-3895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16331223#comment-16331223
]
Vrushali C commented on YARN-3895:
----------------------------------
Hi [~jlowe]
We ([~varun_saxena] [~rohithsharma] and I) had a discussion around these
points and wanted to share our thoughts.
{quote} bq. How does the collector authenticate that the AM is allowed to proxy
as that user, or can any AM forge data as other users simply by stating the
data is from so-and-so?
{quote}
So, we store these kind of doAs query related entities in a table called
subApp table. The rowkey in this table contains both the subAppUserId as well
as the AM user ID. Although we do not check if the AM is allowed to write as
some user, the entity for this pair of \{AM user, subAppUser ID } will be in
it’s own row. The row key also has the cluster id, entity type, entity id and
entity id prefix.
Sub App Row key format:
{code:java}
{subAppUserId!clusterId!entityType!entityPrefix!entityId!userId}{code}
Therefore, although a rogue AM could write a lot of data as other doAs users,
it would still go to it’s own rows.
{quote}bq. It's less clear to me how this is going to work for the case of an
AM running as one user but working on behalf of multiple other users across
multiple sub-apps. The YARN application only has one set of ACLs, set when it
is submitted by the service user.
{quote}
So in the case of AM running as one user and executing doAs queries, we are now
thinking of the following enhancement to earlier proposal:
- With every timeline entity, we propose to have a TimelineEntityACLs object
inside it. (This TimelineEntityACLs does not exist yet in the current code.)
- The AM can populate this TimelineEntityACLs object with the ApplicationACLs
and it will be part of the TimelineEntity it is writing. When there exist
additional DAG ACLs as in the case of doAs queries, they can also be added to
TimelineEntityACLs of that entity.
- In this way, each timeline entity can have it’s allowed users/groups.
At the backend, we think we can store these allowed users and allowed groups as
column values in the tables per entity and at query time, we can confirm if the
user making the query is part of allowed users list or is in a group that is
part of allowed groups list.
We started thinking of storing it in columns rather than cell tags since the
ACLs would be too much info to store for each cell. Since each timeline entity
is in it’s own row, each row having columns for allowed users and allowed
groups should work per entity.
Would appreciate your feedback on this updated approach.
> Support ACLs in ATSv2
> ---------------------
>
> Key: YARN-3895
> URL: https://issues.apache.org/jira/browse/YARN-3895
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: timelineserver
> Affects Versions: YARN-2928
> Reporter: Varun Saxena
> Assignee: Varun Saxena
> Priority: Major
> Labels: YARN-5355
>
> This JIRA is to keep track of authorization support design discussions for
> both readers and collectors.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
