Related: https://issues.apache.org/jira/browse/MESOS-3024 "HTTP endpoint authN is enabled merely by specifying --credentials" We cannot rely on --credentials as the only way to enable/disable HTTP endpoints, as web auth should not be tied so closely to framework/slave auth. There needs to be a separate switch, as there is for --authenticate[_frameworks] and --authenticate_slaves. Or maybe it's all encoded in the ACLs?
On Thu, Jul 16, 2015 at 11:25 AM, Benjamin Mahler <[email protected] > wrote: > I wasn't referring to default configuration, but yeah we should improve > that! > > Some operators already run production setups not using the default > configuration (e.g. --credentials and non-permissive --acls so that only > authenticated / authorized frameworks can connect and run workloads). > > For these folks, when we added the /teardown endpoint, authentication and > authorization was automatically in place given their existing flags. The > groundwork in the code is in place to do this for the quota endpoint as > well, so should not be pretty easy to follow this precedent. Unless I'm > missing something? :) > > On Wed, Jul 15, 2015 at 3:47 PM, Cody Maloney <[email protected]> wrote: > > > I would note for that though that a default configuration of Mesos allows > > anyone at any time to launch a container with no isolation / no > meaningful > > isolation from the base machines, and run arbitrary commands inside that > > container as root on the box. Locking other things down by default / > > leaving them off by default won't improve the "default" security > > configuration of a Mesos cluster. > > > > > > > > On Wed, Jul 15, 2015 at 3:02 PM Benjamin Mahler < > [email protected] > > > > > wrote: > > > > > If we omit authz for admin endpoints like this, it would be great to > > > disable them _by default_ until we have proper authorization in place. > > > Otherwise operators will accidentally leave admin endpoints open for > > anyone > > > to hit! :) > > > > > > On Wed, Jul 15, 2015 at 12:07 PM, Alex Rukletsov <[email protected]> > > > wrote: > > > > > > > Folks, > > > > > > > > We have updated the design doc [1] based on numerous comments on the > > v1. > > > > > > > > There is one substantial design question left: what entity should > > decide > > > > whether a quota can be granted: the Master, an allocator, or a > separate > > > > "Quota Manager". I have described pros and cons of each in the doc, > > > please > > > > look inside for more information. > > > > > > > > Apart of that, I have made the following amendments: > > > > * Clarified the absence of authz and how this mitigate that with > > > firewall; > > > > * Updated confusing naming: quota is a pair of guaranteed resource > and > > > > limit; > > > > * Added a safety design principal; > > > > * Updated section explaining granting quota decision; > > > > * Updated QuotaInfo protobuf; > > > > * Added an alternative quota implementation via dynamic reservations; > > > > * Updated HTTP api to be more REST-like; > > > > * Added more ideas to the wip Allocator section. > > > > > > > > Please have a look and check whether your concerns have been > addressed. > > > > > > > > [1]: > > > > > > > > > > > > > > https://docs.google.com/document/d/16iRNmziasEjVOblYp5bbkeBZ7pnjNlaIzPQqMTHQ-9I/edit# > > > > > > > > On Fri, Jul 10, 2015 at 8:52 AM, Jörg Schad <[email protected]> > > wrote: > > > > > > > > > I would like to propose one alternative MVP proposal for the > actual > > > > quota > > > > > implementation. > > > > > > > > > > Instead of making changes to the allocator we could have an > allocator > > > > > agnostic “Quota manager” which builds on top the existing dynamic > > > > > reservations. > > > > > > > > > > Beyond MVP, we would still allow for allocator based > implementations > > > for > > > > > more complex quota mechanism, but this quota manager could also > offer > > > > quota > > > > > support for allocators which are not aware of quota (TBD). > > > > > > > > > > > > > > > General Flow: > > > > > > > > > > - Quota manager leverages dynamic reservations to fulfill quota > > > requests. > > > > > It basically continuously tries to match the desired state (quota > > > > requests) > > > > > with the actual state (dynamic reservations). > > > > > > > > > > - it receives quota requests from master > > > > > > > > > > - using (approximate) slave usage information it selects target > > > > slave/agent > > > > > > > > > > - requests to dynamic reservation (HTTP endpoint?), if fails retry > > > > > > > > > > - Master should notify QM of slave failures and reregistrations > > > > > > > > > > - in case of slave failures needs to request new reservation > > > > > > > > > > - in case of slave reregistrations might need to unreserve > > > > > > > > > > Required state of “Quota Manager” > > > > > > > > > > - current dynamic reservations > > > > > > > > > > - current granted quota > > > > > > > > > > - approximate slave available resources (in order to decide on > which > > > > slave > > > > > to /reserve, but doesn’t matter if slightly out of sync -> in worst > > > case > > > > > /reserve fails and we have to retry) > > > > > > > > > > Failover > > > > > > > > > > - current granted quota are persisted in registry by > > master > > > > > > > > > > - current dynamic reservations are reconstructed from slave > > > > reregistration > > > > > > > > > > Master needs to propagate information about slave failures to Quota > > > > > Manager, as it might need to create new dynamic reservation in that > > > case > > > > > > > > > > > > > > > Advantages compared to allocator based implementation: > > > > > > > > > > - no need to change allocator(s) for MVP > > > > > > > > > > - quota support for external quota-agnostic allocators > > > > > > > > > > - re-using existing mechanisms > > > > > > > > > > - minimal implementation effort for MVP > > > > > > > > > > - almost free support for quota chunks (even in MVP) as dynamic > > > > > reservations are per slave > > > > > > > > > > Disadvantages > > > > > > > > > > - allocator based quota implementation still needed for more > > elaborate > > > > > implementations > > > > > > > > > > - as dynamic reservations do not account towards fair share, so > > > wouldn’t > > > > > quota based on this implementation. In my opinion this is not a > real > > > > > problem as a) we did not really define the semantics of quota and > b) > > > fair > > > > > share is a allocator internal (i.e. DRF internal) notion so other > > > > allocator > > > > > implementations are free to do that differently anyhow. > > > > > > > > > > Looking forward to feedback! > > > > > Jörg > > > > > > > > > > On Thu, Jul 9, 2015 at 11:52 PM, Tomás Senart <[email protected] > > > > > > wrote: > > > > > > > > > > > What about "Global Reservations"? > > > > > > > > > > > > On Thu, Jul 9, 2015 at 3:25 PM, Marco Massenzio < > > [email protected] > > > > > > > > > > wrote: > > > > > > > > > > > > > I've added my twocent in the doc - my vote goes for "Guaranteed > > > > > > Allocation" > > > > > > > - not as catchy as "Quota" (and will make classes' naming a > > > > challenge!) > > > > > > but > > > > > > > maybe more helpful in the long-term. > > > > > > > > > > > > > > Anyone has a better suggestion, please do... I can't really say > > I'm > > > > > > > super-excited by Guaranteed Allocation myself! > > > > > > > > > > > > > > *Marco Massenzio* > > > > > > > *Distributed Systems Engineer* > > > > > > > > > > > > > > On Thu, Jul 9, 2015 at 1:48 AM, Alex Rukletsov < > > > [email protected]> > > > > > > > wrote: > > > > > > > > > > > > > > > And you're not the only one who were confused by the > > terminology! > > > > One > > > > > > of > > > > > > > > the alternatives that didn't make it to the public doc was > > > > > > "cluster-wide > > > > > > > > dynamic reservations". The reason we preferred "quota" to " > ... > > > > > > > > reservation" is because the latter is already overloaded with > > > > > meanings > > > > > > in > > > > > > > > Mesos world (static reservations, dynamic reservations). I > have > > > > hoped > > > > > > the > > > > > > > > Terminology section would have helped to avoid the confusion, > > > but I > > > > > see > > > > > > > it > > > > > > > > doesn't. We'll think about how we can solve the problem, we > > > > > definitely > > > > > > > > don't want to create one more "libprocess process represented > > as > > > a > > > > > > thread > > > > > > > > in an OS process" ; ). > > > > > > > > > > > > > > > > I see your point regarding authorization, you're not alone > here > > > > > either > > > > > > : > > > > > > > ). > > > > > > > > Some folks mentioned that the lack of authz is a blocker and > > will > > > > > > prevent > > > > > > > > them from upgrading the cluster. I would propose to treat MVP > > as > > > > > > > > experimental feature: use it at your own risk or disable > > > endpoints > > > > > > > related > > > > > > > > to quota and hence the entire feature. Does it make sense? > > > > > > > > > > > > > > > > On Wed, Jul 8, 2015 at 7:10 PM, James Peach < > [email protected]> > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > On Jul 4, 2015, at 3:15 AM, Alex Rukletsov < > > > > [email protected]> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Folks, > > > > > > > > > > > > > > > > > > > > Jörg and I are working on adding *quota* support to > Mesos. > > > > Quota > > > > > > can > > > > > > > be > > > > > > > > > > described as cluster-wide dynamic reservation. I would > like > > > to > > > > > > share > > > > > > > > the > > > > > > > > > > design doc [1] to gather community feedback early in the > > > design > > > > > > > phase. > > > > > > > > > > > > > > > > > > The most confusing part of this document to me was the > > 'quota' > > > > > > > > > terminology. Quotas normally refer to administrative limits > > > (esp. > > > > > > disk > > > > > > > > > quotas with hard and soft limits), not reserving resources. > > > Since > > > > > > what > > > > > > > > you > > > > > > > > > are describing is an extension to the resource reservation > > > > system, > > > > > it > > > > > > > > would > > > > > > > > > be clearer if it was described in those terms. > > > > > > > > > > > > > > > > > > I was also concerned that access control / authorization is > > not > > > > > > planned > > > > > > > > > for the initial implementation. I think that if Mesos is to > > > have > > > > an > > > > > > > > > authorization policy, it should be applied uniformly > > following > > > > the > > > > > > > > > principle of least surprise. > > > > > > > > > > > > > > > > > > > The doc is work in progress, especially the part related > to > > > > quota > > > > > > > > support > > > > > > > > > > in the allocator. We think we can start working on adding > > > quota > > > > > > > support > > > > > > > > > to > > > > > > > > > > Mesos Master while fleshing out the design for how quota > is > > > > > handled > > > > > > > by > > > > > > > > > the > > > > > > > > > > built-in allocator. > > > > > > > > > > > > > > > > > > > > While working on the design, we faced some challenges and > > > > design > > > > > > > > > questions. > > > > > > > > > > One of them is what decisions should be deferred to > > allocator > > > > and > > > > > > > what > > > > > > > > > can > > > > > > > > > > be decided by the Master. We elaborate on this in the > doc. > > > > > > > > > > > > > > > > > > > > Looking forward to your feedback! > > > > > > > > > > > > > > > > > > > > [1]: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://docs.google.com/document/d/16iRNmziasEjVOblYp5bbkeBZ7pnjNlaIzPQqMTHQ-9I/edit?usp=sharing > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
