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