You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@mesos.apache.org by John Omernik <jo...@omernik.com> on 2015/12/08 17:12:35 UTC
Mesos ACL User
In crafting my ACLs, I found that I would like to have a situation where
groups were used instead of just user... i.e. if I have a certain frame,
perhaps a dev instance of Marathon, I want folks in the dev group to all be
able to to run frameworks as themselves. Right now, have a principal that
can run in any role and with any user, prn_prodcontrol. That works for me.
Then I have a principal that is my devcontrol. So I register dev Marathon
with that, and now anyone who has my credentials for the dev marathon, can
submit marathon jobs, which is cool, however, they can only do it as
unixdevuser, which is my unix user on every box... that's cool too. Also,
the marathondev framework can only operate in the dev role.
{
"register_frameworks": [
{ "principals": { "values": ["prn_prodcontrol"] }, "roles": { "type":
"ANY"}},
{ "principals": { "values": ["prn_devcontrol"] }, "roles": {"values":
["dev"]}}
]
"run_tasks": [
{ "principals": { "values": ["prn_prodcontrol"] }, "users": { "type":
"ANY"}},
{ "principals": { "values": ["prn_devcontrol"] }, "users": {"values":
["unixdevuser"]}}
]
}
What would be ideal is if I have a group marathondevgrp (unix group on all
nodes) and then I register the marathondev framework with principle
prn_devcontrol, having an ACL that stated...
{
"register_frameworks": [
{ "principals": { "values": ["prn_prodcontrol"] }, "roles": { "type":
"ANY"}},
{ "principals": { "values": ["prn_devcontrol"] }, "roles": {"values":
["dev"]}}
]
"run_tasks": [
{ "principals": { "values": ["prn_prodcontrol"] }, "users": { "type":
"ANY"}},
{ "principals": { "values": ["prn_devcontrol"] }, "users": {"values":
["marathondevgrp"]}}
]
}
That it would allow a task to run in the devmarathon as any unix user in
that group. This would allow me to have dev users run frameworks as
themselves (for data access control on my shared filesystem) and still have
the freedom to submit to marathon (dev).
So does ACLs support groups? Is this something that would be difficult to
add? Thoughts about other approach to achieve similar results?
Thanks!
John
Re: Mesos ACL User
Posted by Vinod Kone <vi...@apache.org>.
Mesos doesn't understand user groups yet, so you can't setup ACLs on them.
On Wed, Dec 9, 2015 at 11:33 AM, John Omernik <jo...@omernik.com> wrote:
> Well the mesos slaves are running as root, so they can run any task as any
> user. What I believe this is trying to do is using authentication in Mesos,
> ensure that only certain folks, with the secret can run as certain users.
> Thus, if I have a prn_devcontrol principal and secret, that can be used by
> a marathon framework I start. My devs can use that framework, and now they
> can only run tasks as themselves. Now, obviously there are concerns here...
> a single shared password defeats accountability, This would not be a
> concern if I gave a principal to each user. Of course, then I have to
> restart mesos masters each time I change the ACLs which is also a
> challenge.
>
>
>
> On Wed, Dec 9, 2015 at 11:52 AM, haosdent <ha...@gmail.com> wrote:
>
>> >That it would allow a task to run in the devmarathon as any unix user
>> in that group.
>> I think in Linux only root would run task with other user. For normal
>> users, although they are in same group, it also not allowed to run task
>> with other account except use sudo. So "roles" in ACL is more close to what
>> you expect here?
>>
>> On Wed, Dec 9, 2015 at 12:12 AM, John Omernik <jo...@omernik.com> wrote:
>>
>>> In crafting my ACLs, I found that I would like to have a situation where
>>> groups were used instead of just user... i.e. if I have a certain frame,
>>> perhaps a dev instance of Marathon, I want folks in the dev group to all be
>>> able to to run frameworks as themselves. Right now, have a principal that
>>> can run in any role and with any user, prn_prodcontrol. That works for me.
>>> Then I have a principal that is my devcontrol. So I register dev Marathon
>>> with that, and now anyone who has my credentials for the dev marathon, can
>>> submit marathon jobs, which is cool, however, they can only do it as
>>> unixdevuser, which is my unix user on every box... that's cool too. Also,
>>> the marathondev framework can only operate in the dev role.
>>>
>>>
>>> {
>>> "register_frameworks": [
>>> { "principals": { "values": ["prn_prodcontrol"] }, "roles": { "type":
>>> "ANY"}},
>>> { "principals": { "values": ["prn_devcontrol"] }, "roles": {"values":
>>> ["dev"]}}
>>> ]
>>> "run_tasks": [
>>> { "principals": { "values": ["prn_prodcontrol"] }, "users": { "type":
>>> "ANY"}},
>>> { "principals": { "values": ["prn_devcontrol"] }, "users": {"values":
>>> ["unixdevuser"]}}
>>> ]
>>> }
>>>
>>>
>>> What would be ideal is if I have a group marathondevgrp (unix group on
>>> all nodes) and then I register the marathondev framework with principle
>>> prn_devcontrol, having an ACL that stated...
>>>
>>>
>>> {
>>> "register_frameworks": [
>>> { "principals": { "values": ["prn_prodcontrol"] }, "roles": { "type":
>>> "ANY"}},
>>> { "principals": { "values": ["prn_devcontrol"] }, "roles": {"values":
>>> ["dev"]}}
>>> ]
>>> "run_tasks": [
>>> { "principals": { "values": ["prn_prodcontrol"] }, "users": { "type":
>>> "ANY"}},
>>> { "principals": { "values": ["prn_devcontrol"] }, "users": {"values":
>>> ["marathondevgrp"]}}
>>> ]
>>> }
>>>
>>> That it would allow a task to run in the devmarathon as any unix user in
>>> that group. This would allow me to have dev users run frameworks as
>>> themselves (for data access control on my shared filesystem) and still have
>>> the freedom to submit to marathon (dev).
>>>
>>>
>>> So does ACLs support groups? Is this something that would be difficult
>>> to add? Thoughts about other approach to achieve similar results?
>>>
>>> Thanks!
>>>
>>> John
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Best Regards,
>> Haosdent Huang
>>
>
>
Re: Mesos ACL User
Posted by John Omernik <jo...@omernik.com>.
Well the mesos slaves are running as root, so they can run any task as any
user. What I believe this is trying to do is using authentication in Mesos,
ensure that only certain folks, with the secret can run as certain users.
Thus, if I have a prn_devcontrol principal and secret, that can be used by
a marathon framework I start. My devs can use that framework, and now they
can only run tasks as themselves. Now, obviously there are concerns here...
a single shared password defeats accountability, This would not be a
concern if I gave a principal to each user. Of course, then I have to
restart mesos masters each time I change the ACLs which is also a
challenge.
On Wed, Dec 9, 2015 at 11:52 AM, haosdent <ha...@gmail.com> wrote:
> >That it would allow a task to run in the devmarathon as any unix user in
> that group.
> I think in Linux only root would run task with other user. For normal
> users, although they are in same group, it also not allowed to run task
> with other account except use sudo. So "roles" in ACL is more close to what
> you expect here?
>
> On Wed, Dec 9, 2015 at 12:12 AM, John Omernik <jo...@omernik.com> wrote:
>
>> In crafting my ACLs, I found that I would like to have a situation where
>> groups were used instead of just user... i.e. if I have a certain frame,
>> perhaps a dev instance of Marathon, I want folks in the dev group to all be
>> able to to run frameworks as themselves. Right now, have a principal that
>> can run in any role and with any user, prn_prodcontrol. That works for me.
>> Then I have a principal that is my devcontrol. So I register dev Marathon
>> with that, and now anyone who has my credentials for the dev marathon, can
>> submit marathon jobs, which is cool, however, they can only do it as
>> unixdevuser, which is my unix user on every box... that's cool too. Also,
>> the marathondev framework can only operate in the dev role.
>>
>>
>> {
>> "register_frameworks": [
>> { "principals": { "values": ["prn_prodcontrol"] }, "roles": { "type":
>> "ANY"}},
>> { "principals": { "values": ["prn_devcontrol"] }, "roles": {"values":
>> ["dev"]}}
>> ]
>> "run_tasks": [
>> { "principals": { "values": ["prn_prodcontrol"] }, "users": { "type":
>> "ANY"}},
>> { "principals": { "values": ["prn_devcontrol"] }, "users": {"values":
>> ["unixdevuser"]}}
>> ]
>> }
>>
>>
>> What would be ideal is if I have a group marathondevgrp (unix group on
>> all nodes) and then I register the marathondev framework with principle
>> prn_devcontrol, having an ACL that stated...
>>
>>
>> {
>> "register_frameworks": [
>> { "principals": { "values": ["prn_prodcontrol"] }, "roles": { "type":
>> "ANY"}},
>> { "principals": { "values": ["prn_devcontrol"] }, "roles": {"values":
>> ["dev"]}}
>> ]
>> "run_tasks": [
>> { "principals": { "values": ["prn_prodcontrol"] }, "users": { "type":
>> "ANY"}},
>> { "principals": { "values": ["prn_devcontrol"] }, "users": {"values":
>> ["marathondevgrp"]}}
>> ]
>> }
>>
>> That it would allow a task to run in the devmarathon as any unix user in
>> that group. This would allow me to have dev users run frameworks as
>> themselves (for data access control on my shared filesystem) and still have
>> the freedom to submit to marathon (dev).
>>
>>
>> So does ACLs support groups? Is this something that would be difficult to
>> add? Thoughts about other approach to achieve similar results?
>>
>> Thanks!
>>
>> John
>>
>>
>>
>>
>>
>
>
> --
> Best Regards,
> Haosdent Huang
>
Re: Mesos ACL User
Posted by haosdent <ha...@gmail.com>.
>That it would allow a task to run in the devmarathon as any unix user in
that group.
I think in Linux only root would run task with other user. For normal
users, although they are in same group, it also not allowed to run task
with other account except use sudo. So "roles" in ACL is more close to what
you expect here?
On Wed, Dec 9, 2015 at 12:12 AM, John Omernik <jo...@omernik.com> wrote:
> In crafting my ACLs, I found that I would like to have a situation where
> groups were used instead of just user... i.e. if I have a certain frame,
> perhaps a dev instance of Marathon, I want folks in the dev group to all be
> able to to run frameworks as themselves. Right now, have a principal that
> can run in any role and with any user, prn_prodcontrol. That works for me.
> Then I have a principal that is my devcontrol. So I register dev Marathon
> with that, and now anyone who has my credentials for the dev marathon, can
> submit marathon jobs, which is cool, however, they can only do it as
> unixdevuser, which is my unix user on every box... that's cool too. Also,
> the marathondev framework can only operate in the dev role.
>
>
> {
> "register_frameworks": [
> { "principals": { "values": ["prn_prodcontrol"] }, "roles": { "type":
> "ANY"}},
> { "principals": { "values": ["prn_devcontrol"] }, "roles": {"values":
> ["dev"]}}
> ]
> "run_tasks": [
> { "principals": { "values": ["prn_prodcontrol"] }, "users": { "type":
> "ANY"}},
> { "principals": { "values": ["prn_devcontrol"] }, "users": {"values":
> ["unixdevuser"]}}
> ]
> }
>
>
> What would be ideal is if I have a group marathondevgrp (unix group on all
> nodes) and then I register the marathondev framework with principle
> prn_devcontrol, having an ACL that stated...
>
>
> {
> "register_frameworks": [
> { "principals": { "values": ["prn_prodcontrol"] }, "roles": { "type":
> "ANY"}},
> { "principals": { "values": ["prn_devcontrol"] }, "roles": {"values":
> ["dev"]}}
> ]
> "run_tasks": [
> { "principals": { "values": ["prn_prodcontrol"] }, "users": { "type":
> "ANY"}},
> { "principals": { "values": ["prn_devcontrol"] }, "users": {"values":
> ["marathondevgrp"]}}
> ]
> }
>
> That it would allow a task to run in the devmarathon as any unix user in
> that group. This would allow me to have dev users run frameworks as
> themselves (for data access control on my shared filesystem) and still have
> the freedom to submit to marathon (dev).
>
>
> So does ACLs support groups? Is this something that would be difficult to
> add? Thoughts about other approach to achieve similar results?
>
> Thanks!
>
> John
>
>
>
>
>
--
Best Regards,
Haosdent Huang