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 <[email protected]> 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 <[email protected]> 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 >
