[
https://issues.apache.org/jira/browse/MESOS-4772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15199191#comment-15199191
]
Adam B commented on MESOS-4772:
-------------------------------
Sorry for the hasty decision to add a TaskInfo.owner. After more discussion,
[~vinodkone] and I now favor a namespace approach (similar to Marathon's
app-groups or [~jdef]'s suggestion), instead of the previously discussed
task-owner approach. Also notice that I've linked this ticket under the Epic
MESOS-4931 where [~js84] is designing authorization-based filtering of state
endpoints. Let's discard [~nfnt]'s previous patch while we confirm what we
really want to do. Allow me to explain some of the recent thinking.
What we have now: flat roles
1. Each framework can only have a single role, but multiple frameworks can
share a role. A role does not have a parent role.
2. Resources may be reserved for a role, and volumes created only within the
resources reserved for a role.
3. Quota and DRF weights may be assigned to each role, and resources for a
framework are allocated to its role.
4. Problem: Every http user can see every framework/role's tasks and sandbox
data.
We could (and should) add coarse-grained access control:
1. Add Authz around state json to restrict which users can see
tasks/executors/frameworks from which roles.
2. Add Authz around sandbox access to restrict which users can see executor
sandboxes belonging to which roles.
But coarse-grained per-role access control doesn't help the multi-user
framework use case, since every user in the framework can see the entire
role/framework.
We could (but shouldn't) have multi-user frameworks pass TaskInfo.owner, as
previously proposed:
1. Add Authz around state json to restrict which users can see
tasks/executors/frameworks owned by which (other) users.
2. Add Authz around sandbox access to restrict which users can see executor
sandboxes owned by which (other) users.
TaskInfo.owner provides appropriate fine-grained access control if you only
want a user to ever see their own tasks. But as soon as you want to share one
user's task/sandbox with another, you are forced to grant the second user
access to all tasks/sandboxes owned by the first user. This is not flexible
enough for most real-world use cases, where users work on some projects
together but not others.
In the long run, we've discussed hierarchies both above and below roles.
1. Hierarchical framework groups (outer roles): Although a framework only has a
single role, that role may belong to another role, up a role hierarchy.
2. These hierarchical outer roles would be great for organizing quota and DRF
weights across many frameworks.
3. Hierarchical task groups (inner roles): Although a framework has a single
role, it can dynamically create roles underneath its role in the hierarchy.
4. These inner roles would be great for organizing quota/weights between groups
of apps/projects/jobs in a framework.
5. These inner roles would be ideal for associating reserved resources and
volumes to specific apps/projects/jobs, so the framework has less bookkeeping
to do.
6. These inner roles could be used to grant users visibility of one group of
apps/projects/jobs without granting access to all others with the same
owner/role.
The above situation would be great, but there are many pieces to that puzzle,
and it'll take us a while to get there.
We could start by introducing TaskInfo.group (name TBD) for visibility, but not
reservations/volumes/quota/DRF.
1. Multi-user frameworks would pass Mesos the app/project/job name (including
hierarchy) when creating a task.
2. Add Authz around state json to restrict which users can see
tasks/executors/frameworks from which "<role>:<taskgroup>".
3. Add Authz around sandbox access to restrict which users can see executor
sandboxes belonging to which "<role>:<taskgroup>".
This model allows admins to assign users to projects within frameworks as they
please, and those users will only be able to see the tasks/sandboxes for their
projects. A particular project may be visible only to a single user, or to
multiple users. Sharing one project between two users has no impact on their
access to other projects.
We could easily add the new TaskInfo.group field now, but the difficult part
(besides naming) is figuring out how we might integrate the concept with
hierarchical roles in the future. Can we base ACLs on "role:taskgroup" now, and
then change TaskInfo.group to TaskInfo.role and base ACLs on "role" in the
future? Or does introducing a separate "taskgroup" concept now prevent us from
incorporating it into "role" in the future?
> TaskInfo/ExecutorInfo should include owner information
> ------------------------------------------------------
>
> Key: MESOS-4772
> URL: https://issues.apache.org/jira/browse/MESOS-4772
> Project: Mesos
> Issue Type: Improvement
> Components: security
> Reporter: Adam B
> Assignee: Jan Schlicht
> Labels: authorization, mesosphere, ownership, security
>
> We need a way to assign fine-grained ownership to tasks/executors so that
> multi-user frameworks can tell Mesos to associate the task with a user
> identity (rather than just the framework principal+role). Then, when an HTTP
> user requests to view the task's sandbox contents, or kill the task, or list
> all tasks, the authorizer can determine whether to allow/deny/filter the
> request based on finer-grained, user-level ownership.
> Some systems may want TaskInfo.owner to represent a group rather than an
> individual user. That's fine as long as the framework sets the field to the
> group ID in such a way that a group-aware authorizer can interpret it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
