Re: [libvirt] ACLs for libvirt

On Wed, Nov 23, 2011 at 12:27:27PM -0500, Dave Allan wrote: > On Wed, Nov 23, 2011 at 06:17:46PM +0100, Michal Privoznik wrote: > > Hi all, > > > > I'd like to implement this new feature for libvirt. However, I think we > > should settle down on design first. My biggest concern is choosing the > > right level on on which ACLs will be implemented. Should be interested > > only in (user, API), or with more granularity (user, API, API's parameters)? > > Or should we take the RBAC path? > > How should we even identify and authorize users? > > > > My initial though is to create framework which can be used then to > > implement ACLs on any level we want. > > My $.02 is that this has the potential to be such a huge project that > we need to come up with a design that lets us bite off as much as we > want at one time, leaving the rest of libvirt's functionality > operating as it always has. So, for example, we could start by > creating an ACL that would let a particular user boot and shutdown but > not edit a VM; later when we wanted to let particular users connect to > the VM's console, we could implement that, and so on. It needs to be > done in a consistent way so that future additions are clearly slotted > into the existing design. I tend to agree, I think like for the security module, we should provide an access control driver API with exhaustive parameters, but as a first step implement a simple user based driver. We just need to make sure that it would allow to implement a full RBAC kind of driver. It seems to me that the driver just need to plug in the API entry points, i.e. mostly libvirt.c. I would probably not pass all APIs parameters at the API level but some function ID, and main arguments: - connection - domain - network - interface - pool - vol - device - snapshot - secret - stream - ... - and some kind of string (could be used for xml, uuid, device path, or migration URI for example) The first use of that driver could be to implemenent the read-only mode of connections internally. Might indicate that being able to stack multiple access control driver as an interesting feature (i.e. how to finer restrict read-only mode with extra rules). I think a lot of the code in the driver front-end should be fairly mechanical ... dunno if we should generate it from the API description though, just an idea.