[
https://issues.apache.org/jira/browse/MESOS-8018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16181469#comment-16181469
]
James Peach commented on MESOS-8018:
------------------------------------
[~zhitao] What about the security considerations of this? Would a task be able
to create more privileged tasks?
> 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)
