[jira] [Comment Edited] (MESOS-8018) Allow framework to opt-in to forward executor's JWT token to the tasks

["Zhitao Li (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MESOS-8018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16184562#comment-16184562 ] 

Zhitao Li edited comment on MESOS-8018 at 9/28/17 6:00 PM:
-----------------------------------------------------------

[~jamespeach] If the framework *opt-in* to this behavior, then the task will be allowed to whatever the (default) executor can do through agent HTTP API, possibly including launching a privileged task within the executor container tree, if other part of AuthZ permits that.


was (Author: zhitao):
[~jamespeach] If the framework *opt-in* to this behavior, then the task will be allowed to whatever the (default) executor can do through agent HTTP API, possibly including launching a privileged task within the executor container tree.

> Allow framework to opt-in to forward executor's JWT token to the tasks
> ----------------------------------------------------------------------
>
>                 Key: MESOS-8018
>                 URL: https://issues.apache.org/jira/browse/MESOS-8018
>             Project: Mesos
>          Issue Type: Improvement
>            Reporter: Zhitao Li
>
> Nested container API is an awesome feature and enabled a lot of interesting use cases. A pattern we have seen multiple times is that a task (often the only one) launched by default executor wants to further creates containers nested behind itself (or the executor) to run some different workload.
> Because the entire request is 1) completely local to the executor container, 2) okay to be bounded within the executor's lifecycle, we'd like to allow the task to use the mesos agent API directly to create these nested containers. However, it creates a problem when we want to enable HTTP executor authentication because the JWT auth tokens are only available to the executor so the task's API request will be rejected.
> Requiring framework owner to fork or create a custom executor simply for this purpose also seems a bit too heavy.
> My proposal is to allow framework to opt-in with some field so that the launched task will receive certain environment variables from default executor, so the task can "act upon" the executor. One idea is to add a new field to allow certain environment variables to be forwarded from executor to task.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)