My vote is +1 for implicit roles for simplicity. Also, it is true that a blocker right now is that we currently cannot add roles on the fly. This makes features like quota and dynamic reservations a challenge to make use of. I'm not sure why we need dynamic roles when we would have dynamic ACL's for the implicit roles in addition to framework authentication. Is there a use case or scenario that I am missing where dynamic roles are important? I'd prefer the simplest approach if possible.
Thanks, Elizabeth On Fri, Dec 4, 2015 at 8:26 AM, Alex Rukletsov <[email protected]> wrote: > I'm reluctant to introduce multiple role management mechanisms because of > mainly two reasons: avoid spreading our efforts and avoid confusion for > operators (legacy roles, implicit roles, dynamic roles). > > Another thing is that after talking to some folks, I realized that the > blocker right now is that people cannot add roles on the fly. Hence > operators can hardly use features like quota or dynamic reservations. Hence > I would rather enable adding roles on the fly _now_ and refine it later. > Implicit roles seem less coupled with other stories involving roles > (weights, ACLs, quotas) and allow us to ship an MVP sooner (this my > intuition). > > > At the very beginning of this thread (Nov 26), Neil said about Implicit > > Roles: > > > In a sense, "all roles" exist, so there is no need to store the set of > > > legal roles or provide endpoints to modify them. > > - As I rethink this, I tend to disagree. Even with implicit/unknown roles > > allowed by default ("all roles exist"), it may still be necessary to use > > ACLs to specify the set of legal roles, and although we may not need > > endpoints just to add/remove role names, we will need endpoints to > > update/remove/list RoleInfos. Maybe we should think of these differently > as > > two complementary features: Implicit Roles Allowed by Default, and > Dynamic > > RoleInfos. > After talking to Neil about that, I have the following picture in mind. All > roles exist, but some are currently "visible". A role is "visible" to the > master if it is mentioned at least once (think reference counting smart > pointers): there is an ACL mentioning this role, a quota for the role is > set, a framework is registered with this role, and so on. IIUC visible > roles are equivalent to current roles stored in `Master::Role` struct (or > `RoleInfo`). > > To the second part of Adam's answer: What does dynamic `RoleInfo` mean? > Currently, it's just a pair `<role, weight>` which is actually dynamic role > weight : ). I'm also not sure we should update `RoleInfo` with any > role-related information. For example, we already do not store role quotas > there, neither dynamically reserved resources are listed there. > > Now, the trickiest part IMO is to do "reference counting" right: maintain a > full list of visible roles without orphans (do not "leak" roles if you > want). However, I think, it's a reasonable engineering effort for > simplicity for operators. > > > > And now I'll respond to Yong's most recent points on Implicit Roles: > > > 1. Does not need a specified endpoint for role management, but more > > > endpoints should be provided to manage role's related object, such as > the > > > dynamic management for Weight, Grace Period (which is involved by > > > Optimistic Offers), etc. > > + Agreed. Implicit Roles on their own provide some value to smaller, > > trusting companies, but we still need Dynamic ACLs and Dynamic Weights > > before Roles in general are enterprise-ready. Even the Dynamic Roles > > proposal includes Dynamic Weights. And Dynamic ACLs are in increasing > > demand for other reasons. > Opting for implicit roles allows us to free engineering forces to focus on > dynamic ACLs and dynamic role weights! > > > > > 2. Role will be persisted in multiple places. For example, role should > be > > > persist in replicated log when we have dynamic weight, and role also > need > > > be persisted when we have dynamic Grace Period, etc. > > - Not necessarily. Firstly, implicit/unspecified roles with default > values > > don't need to be persisted anywhere. And if a user wants to set > non-default > > RoleInfo settings, they can, and then that info must be persisted, > whether > > there's a framework associated with that role or not. But nothing says > that > > the role (name) must be persisted separately for weights, quota, grace > > period, etc. ACLs are another story, since they are much broader than > just > > roles, and they may actually be sourced externally, e.g. LDAP. > Dynamic roles are persisted in the master *and* implicitly in the cluster. > Master tracks for example quotas and role weights, while re-registering > frameworks — roles with which they register. > > > > > 4. As an operator, s/he must have more knowledges to use multiple > > > endpoints to manage role's related objects. and the operator must > guarantee > > > consistency when configuring ACLs, weights, Grace Period, quota, etc. > > + Good point. If we're going to have more and more metadata associated > with > > roles, it may make sense to be able to query and modify this data as a > > unit. Even if we adopt the idea that an unspecified role is implicitly > > allowed and given default metadata if it isn't explicitly disallowed by > > ACLs, we could still use the Dynamic Roles proposal's update/remove/list > > endpoints for those roles where we did express metadata. Note: The > > 'addRole' operation becomes identical to 'updateRole' if you don't check > > whether the role previously existed. > Why can't we have a single endpoint for viewing and manipulating implicit > roles? Imagine the following sequence of operator requests: > * GET /roles -> {[{name: "prod"}, {name: "hdfs"}]} > * POST /roles/add { name: "test", weight: "0.1" } -> OK > * GET /roles -> {[{name: "prod"}, {name: "hdfs"}, {name: "test", weight: > "0.1"]} > > > I would suggest to join efforts and focus on implicit roles, gather user > feedback and revisit role management later on if needed. > > Thanks, > AlexR > > On Fri, Dec 4, 2015 at 11:30 AM, Adam Bordelon <[email protected]> wrote: > > > Thanks for the discussion so far. Rereading it has helped me understand > the > > relationship/overlap between these two proposals. Here are my thoughts. > > > > TL;DR: Let's do both! Not specifying --roles (or ACLs) should mean that > any > > role can register. Let's also improve the /roles endpoint to > > update/remove/list Role metadata and persist it (although not for just > > adding/removing explicitly allowed role names). > > > > Please keep in mind a previously unmentioned user story: "As a cluster > > admin, I would like to allow authorized principals to register as many > > frameworks+roles as necessary, without manual admin intervention, so that > > each framework can create dynamic reservations and persistent volumes > that > > aren't shared with other frameworks that happen to have the same role." > > > > At the very beginning of this thread (Nov 26), Neil said about Implicit > > Roles: > > > In a sense, "all roles" exist, so there is no need to store the set of > > legal roles or provide endpoints to modify them. > > - As I rethink this, I tend to disagree. Even with implicit/unknown roles > > allowed by default ("all roles exist"), it may still be necessary to use > > ACLs to specify the set of legal roles, and although we may not need > > endpoints just to add/remove role names, we will need endpoints to > > update/remove/list RoleInfos. Maybe we should think of these differently > as > > two complementary features: Implicit Roles Allowed by Default, and > Dynamic > > RoleInfos. > > > > And now I'll respond to Yong's most recent points on Implicit Roles: > > > 1. Does not need a specified endpoint for role management, but more > > endpoints should be provided to manage role's related object, such as the > > dynamic management for Weight, Grace Period (which is involved by > > Optimistic Offers), etc. > > + Agreed. Implicit Roles on their own provide some value to smaller, > > trusting companies, but we still need Dynamic ACLs and Dynamic Weights > > before Roles in general are enterprise-ready. Even the Dynamic Roles > > proposal includes Dynamic Weights. And Dynamic ACLs are in increasing > > demand for other reasons. > > > > > 2. Role will be persisted in multiple places. For example, role should > be > > persist in replicated log when we have dynamic weight, and role also need > > be persisted when we have dynamic Grace Period, etc. > > - Not necessarily. Firstly, implicit/unspecified roles with default > values > > don't need to be persisted anywhere. And if a user wants to set > non-default > > RoleInfo settings, they can, and then that info must be persisted, > whether > > there's a framework associated with that role or not. But nothing says > that > > the role (name) must be persisted separately for weights, quota, grace > > period, etc. ACLs are another story, since they are much broader than > just > > roles, and they may actually be sourced externally, e.g. LDAP. > > > > > 3. Role validation (such as to avoid the typos) depends on ACLs; > > + Correct (at least once we deprecate --roles). But how is managing a > list > > in an ACL different from managing an explicit --roles list, or whatever > > goes into your addRole endpoint? And even with dynamic roles, there's the > > chance that the role spelling in the ACL differs from that in the roles > > list. > > > > > 4. As an operator, s/he must have more knowledges to use multiple > > endpoints to manage role's related objects. and the operator must > guarantee > > consistency when configuring ACLs, weights, Grace Period, quota, etc. > > + Good point. If we're going to have more and more metadata associated > with > > roles, it may make sense to be able to query and modify this data as a > > unit. Even if we adopt the idea that an unspecified role is implicitly > > allowed and given default metadata if it isn't explicitly disallowed by > > ACLs, we could still use the Dynamic Roles proposal's update/remove/list > > endpoints for those roles where we did express metadata. Note: The > > 'addRole' operation becomes identical to 'updateRole' if you don't check > > whether the role previously existed. > > > > And for Yong's Dynamic Roles points: > > > 1. Needs to enhance the exist endpoint /roles to support > > add/update/remove a role, and operator can only use this one endpoint to > > manage all objects (e.g. weight, Grace Period, etc.) which related with > > role. > > + Clarification: I believe you mean that "only operators can use this > > endpoint", meaning that a framework could not add/update/remove its own > > role. > > > > > 2. Role information will only be persisted in one replicated log (Plan > to > > persist RoleInfo when call /roles to add role). > > + I don't think anybody was suggesting otherwise, even with Implicit > Roles. > > Implicit Roles itself has no need for persistence. That's up to Dynamic > > Weights/ACLs/whatever. > > > > > 3. Keep a valid role list in Mesos, and which can be used to prevent > the > > typos and can help to check the correctness when operator configuring > > ACLs, weights, Grace Period, quota, etc. > > - I don't think preventing typos is a strong motivating use case. But > since > > we'll still have to support --roles for a while, it can still be used by > > anybody not satisfied with using ACLs to declare the list of allowed > roles. > > > > In response to Yong's concern about ACLs: > > > My concern is that Implicit Roles and ACLs are independent functions, > > ACLs is focus on the access control rather than prevent a invalid role. > For > > example, if the principal is incorrect, then the authorization will also > > failed when register framework. In addition, as you mean, Implicit roles > > must depend on ACLs? If without ACLs, Implicit roles can work well? > > We'll really only be changing the behavior if --roles is not specified, > > which previously would have meant that no roles are allowed. If that's > > really the desired use case, then it can be expressed through ACLs. More > > likely, somebody setting up a dev/test cluster won't know that they need > to > > set --roles, and may try to register a framework with a new role and > expect > > it to succeed automatically. So, without ACLs or explicit > --roles/weights, > > I suspect (based on actual reported user confusion) that many naive users > > would expect to be able to register with any role. > > > > Thanks for reading this far, > > -Adam- > > > > On Tue, Dec 1, 2015 at 1:10 AM, YongQiao Wang <[email protected]> > > wrote: > > > > > Some design analyse between Implicit Roles and Dynamic Roles: > > > > > > For Implicit Roles: > > > 1. Does not need a specified endpoint for role management, but more > > > endpoints should be provided to manage role's related object, such as > the > > > dynamic management for Weight, Grace Period (which is involved by > > > Optimistic Offers), etc. > > > 2. Role will be persisted in multiple places. For example, role should > be > > > persist in replicated log when we have dynamic weight, and role also > need > > > be persisted when we have dynamic Grace Period, etc. > > > 3. Role validation (such as to avoid the typos) depends on ACLs; > > > 4. As an operator, s/he must have more knowledges to use multiple > > endpoints > > > to manage role's related objects. and the operator must guarantee > > > consistency when configuring ACLs, weights, Grace Period, quota, etc. > > > > > > For Dynamic Roles: > > > 1. Needs to enhance the exist endpoint /roles to support > > add/update/remove > > > a role, and operator can only use this one endpoint to manage all > objects > > > (e.g. weight, Grace Period, etc.) which related with role. > > > 2. Role information will only be persisted in one replicated log (Plan > to > > > persist RoleInfo when call /roles to add role). > > > 3. Keep a valid role list in Mesos, and which can be used to prevent > the > > > typos and can help to check the correctness when operator > > > configuring ACLs, weights, Grace Period, quota, etc. > > > > > > So I think the model of Dynamic Roles is easy to understand and > operate. > > > This is only my understanding, welcome any other comments. > > > > > > On Tue, Dec 1, 2015 at 5:05 PM, YongQiao Wang <[email protected] > > > > > wrote: > > > > > > > @Neil, My concern is that Implicit Roles and ACLs are independent > > > > functions, ACLs is focus on the access control rather than prevent a > > > > invalid role. For example, if the principal is incorrect, then > > > > the authorization will also failed when register framework. In > > addition, > > > as > > > > you mean, Implicit roles must depend on ACLs? If without ACLs, > Implicit > > > > roles can work well? > > > > > > > > On Tue, Dec 1, 2015 at 2:44 PM, Neil Conway <[email protected]> > > > wrote: > > > > > > > >> On Mon, Nov 30, 2015 at 6:53 PM, YongQiao Wang < > > [email protected] > > > > > > > >> wrote: > > > >> >> 1. Choosing a role name > > > >> >> 2. Configuring weights, ACLs, and quotas for the role. > > > >> >> 3. Configuring applications/frameworks to register using that > role. > > > >> > > > > >> > [Yong Qiao] If applications/frameworks do not follow your rules, > and > > > >> > register with another role, then how to prevent? and do we will > > still > > > >> > create this undesirable role in Mesos? Maybe we can only relay on > > ACLs > > > >> to > > > >> > avoid this, but according to my understanding, ACLs is not > required > > in > > > >> > Mesos. > > > >> > > > >> Right -- with implicit roles, the proposal is to use ACLs to > prevent a > > > >> framework from registering as an undesirable role. ACLs are a > > > >> general-purpose mechanism for determining whether a principal should > > > >> be permitted to take an action, so it seems reasonable and > consistent > > > >> to use ACLs for this purpose. > > > >> > > > >> > In addition, I am not sure whether it is make sence to use ACLs > for > > > >> > role validation. > > > >> > > > >> Can you elaborate on your reasoning here? > > > >> > > > >> Thanks, > > > >> Neil > > > >> > > > > > > > > > > > > > >
