mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elizabeth Lingg <eli...@gmail.com>
Subject Re: Fw: Re: Dynamic vs. implicit roles
Date Fri, 04 Dec 2015 18:14:34 GMT
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 <alex@mesosphere.com> 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 <adam@mesosphere.io> 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 <jamesyongqiao@gmail.com>
> > 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 <jamesyongqiao@gmail.com
> >
> > > 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 <neil.conway@gmail.com>
> > > wrote:
> > > >
> > > >> On Mon, Nov 30, 2015 at 6:53 PM, YongQiao Wang <
> > jamesyongqiao@gmail.com
> > > >
> > > >> 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
> > > >>
> > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message