+list On Thu, Feb 13, 2014 at 2:30 PM, Guido Trotter <[email protected]> wrote: > On Fri, Feb 7, 2014 at 6:07 PM, Apollon Oikonomopoulos > <[email protected]> wrote: >> Hi all, >> >> Over the course of the last 4-5 years, I've written at least half a >> dozen non-trivial applications utilizing the RAPI and I must say that >> I've always felt a bit uncomfortable with the lack of fine-grained >> access control in the RAPI implementation. >> >> In the case of an application managing a whole cluster (almost) >> exclusively (think ganetimgr, GWM or synnefo), this is not a big issue; >> access control is implemented in the management layer, which already >> holds user credentials and user/instance associations. And since the >> application is supposed to be able to perform anything on the cluster, >> the security risk of having the application compromised is there anyway. >> >> There are times however where this model doesn't work: >> >> - Applications that are simple and specific in their scope (e.g. only >> updating instance tags automatically) do not (and should not) need to >> add/remove instances and nodes for example. The only way simple >> applications like these can be made usable by untrusted parties, are >> to pass them through an intermediate proxy service that performs >> access control. This in turn makes writing simple utilities >> unnecessarily cumbersome. >> >> - Applications that manage only part of a cluster shouldn't really be >> able to cause damage outside their own domain. With the current >> implementation, a web interface spawning new instances can >> potentially kill instances managed completely outside its scope. >> > > Agreed, the current RAPI model works only for some types of applications. > Of course we'd be happy to integrate changes to expand this to extra > uses (after a design doc discussion). :) > >> Having to go through this process again today, I decided to have a look >> at how easy it would be to implement more fine-grained access control in >> the RAPI. I always thought that having the RAPI implemented as a WSGI >> application would make things easier (being able to use pluggable >> middlewares), but it turns out it's not that difficult with the current >> implementation either. What I wanted to do was have a RAPI user be able >> to only create/control/destroy instances with a specific hostname suffix >> and these are a couple of things I found out in the course of doing >> this: >> >> 1. It turns out that it's pretty easy to add new "roles" in addition to >> "read" and "write" to the RAPI implementation. One only needs to >> append them to the relevant ganeti.rapi.rlib2 R_2_* classes' >> <method>_ACCESS lists. These roles can then be used instead of >> "read" or "write" to grant per-endpoint access. RAPI already has >> support for multiple privilege levels per user, so a first level of >> fine-grained control is trivial to achieve by adding roles like >> "instance_write", "node_write", "group_write", "network_write", >> granting write access to specific resource types only. >> > > Ack. > >> 2. It's also easy to monkey-patch RemoteApiHandler.Authenticate to >> provide our own authentication and authorization for individual >> requests. This allows even more fine-grained control, by inspecting >> the RAPI call request and body. >> > > I wonder if we should have Authentication in RAPI and Authorization at > the LU level, thus not requiring RAPI to understand the request > bodies. > >> What I ended up with, is the attached version of /usr/sbin/ganeti-rapi >> which seems to fulfill my requirements. The only problem with this >> implementation is that I have to replace the actual >> /usr/sbin/ganeti-rapi script (which is a very thin wrapper anyway), thus >> messing with the default Ganeti installation. >> >> What would make things a lot easier from Ganeti's side, would be to >> allow the admin to specify a "middleware" module, providing a single >> RemoteApiHandler class (deriving from the original class) to use instead >> of the original, as a command line argument or via an environment >> variable. This would in turn require a documented and relatively stable >> API for the RemoteApiHandler class, which would become kind of >> semi-public. >> > > We could do that or just implement a pluggable interface that is > called by RAPI for AAA without the need to override the class. This > would have the advantage of making it possible to provide that with > other systems as well, do you think it's worth it? > >> So, it all comes down to the following questions: >> >> - Are there any plans to implement functionality like this at some >> point? > > No, but we'd gladly accept a design/change in this direction. > >> - Does anyone else think this is useful? If yes, I would be willing to >> implement pluggable RAPI handlers, provided that we all agree on the >> API. >> > > Yes, I think it's a very worth contribution. > >> Regards, >> Apollon >> >> P.S.: Are you planning to convert the RAPI implementation to Haskell at some >> point? > > No, not at the moment. I don't think we see the advantage of it, right > now, for such simple code. > > Thanks a lot, > > Guido
-- Guido Trotter Ganeti Engineering Google Germany GmbH Dienerstr. 12, 80331, München Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores Steuernummer: 48/725/00206 Umsatzsteueridentifikationsnummer: DE813741370
