Thanks for the comments. A few responses inline below....


On 1/27/2014 11:53 PM, Shu Ming wrote:
于 2014/1/28 5:07, Frank Novak 写道:

Sounds reasonable by me....
Is it done yet? :-)

I think most of the proposals from Adam are compatible with my previous RFC.   And I have several comments below.



Cheers,
Frank  

-----------------------------------------------------------------------------------------------------------------------
Frank Novak  ( 诺帆 nuò、fān )
STSM, SCEM Open Hypervisor
IBM Linux Technology Center
US:  fnovak@us.ibm.com  ;  Notes:   Frank Novak/Watson/IBM @IBMUS
cell : 919-671-7966
-------------------------------------------------------------------------------------------------------------------------
Adam King rak at linux.vnet.ibm.com
Tue Jan 21 20:38:51 EST 2014 


The proposal is over ambitious in some areas, under ambitious in others.
I'd suggest the following:

*Assumptions:*
The first objective of introducing authorization into Kimchi is to allow
an admin to partition defined VMs for independent, secure use by
different users.

*Scenario:
*Frank is the manager of a team consisting of developers and testers
with a clear separation of responsibility. He already has groups created
on his linux host with user id membership organized by the user's
function. Frank needs to create some VMs for his teams to use. He is the
sole root user on the host.
He wants the developers to be able to manage their VMs' lifecycle, but
not to have permission to increase their VMs resource allocation.
Developers always want as much memory as they can get away with:-)
He wants the testers to have permission to edit the resource allocation
of their VMs. The software needs to be verified with different hardware
configurations, and he doesn't want to have to make every edit for his
testers each time they need to validate a new scenario.
*Resolution:*
Frank creates his VMs.
Those he has created for use by his developers, he assigns the user role
to the development group for each of the VMs granting all his developers
permission to see and manage the life cycle of the VMs
Those he has created for use by his testers, he assigns the admin role
to the test group for each of the VMs granting all his testers
permission to see and take all actions to the VMs


*User Design goals*
An existing system user will only see the resources and actions the user
is authorized to use
An existing system sudo user will see and be able to act on all resources
Actions on a given resource can be restricted with more than binary
granularity. Some authorized users may have more privilege on a resource
than others. ie Some authorized users may be able to edit a VMs resource
definition, while others can only manipulate its life cycle
*System Design Goals*
No new prerequisites are required to be installed or managed. i.e. No
database prerequisite
No new user repository is required beyond what the host system is
configured to use. PAM
The authorization scheme will work with read only user repositories.
Authorization information will be portable. ie. If a VM is moved from
one kimchi host to another, the new host is immediately aware of the
security constraints.
We may need other services like LDAP, nis to keep the users in all the federated hosts are the same.
I agree we would expect a common user repository in a "cluster" environment.

The system is secure. A user will not be able discover the REST API and
invoke actions directly without authorization.
Kimchi managed resources can still be managed by other KVM tools, and
returned to Kimchi without loss of function.
Kimchi 1.2 authorization design is extensible to cover arbitrarily fine
grained constraints

Further, several dependency should be removed to implement this authorization enhancement.
1) A new PAM module to check if a user is a member of a specific group should be implemented.  It is a ".so" library built from C language and python binding is to be added
Is there a  python binding for the groups command? If not, it might be easier to run it behind the scenes than to write a new library to accomplish the same function.
2) A new libvirt XML tag to store the if a user is on the authorization list of a resource.   And most of this work should be done in libvirt community
I think the existing metadata tag in libvirt described at http://libvirt.org/formatdomain.html#elementsMetadata will suit our needs.
Creating new requirements on libvirt will not allow us to deliver on this capability this release.




*Kimchi 1.2 Proposal*
Users in the sudo (admin) group would continue having full access to all
Kimchi functions.Users not in the sudo (admin) group would only have access to VMs that
they are authorized to use.
A VM user could have one of two roles on a given VM
        admin - user has access to all VM actions on the individual VM
        user - user has access to power on, power off, reboot,
Here, we have a map from the sudo users group in Linux host to the super administrator role in Kimchi
1) Users in sudo are mapped to the sudo (admin) role which is a super administrator role in Kimchi, no meta data is needed to store the mapping
Right, members of sudo have an implicit authorization in kimchi, just as they do when logged directly into the host.
2) Users in other groups can be granted to VM user admin role or VM user only role, meta data is needed to store the mapping.
Here is where I think the libvirt metadata will serve our need.
3) Others

I think we need clearly define what is VM user admin role.  IMO, A VM user (admin role)  can have these privileges that the user role dosen't have
1) Attaching and detaching the resource to the VM include network, storage volume resources and etc.  Of course,  the the admin role user should be in the authorized user list of the resource first to do the attaching and detaching
The proposal is that the user with admin role would be allowed to perform all actions on the VM.
2) Others.

The privileges that sudo (admin) role has while A VM user (admin) role doesn't have
1) VM snapshotting is a quite arguable privilege.  Because snapshotting a VM may lead to create a new storage volume in a storage pool that a VM user (admin role) doesn't get permission.
I prefer to move snapshotting  of a VM to the sudo (admin) role
Snapshot will be a feature that we need to extend to the user population.
2) VM "create", "destroy", "update" privilege also belongs to the sudo (admin) role
Agree
3) Template "create", "destroy", "update" also belongs to the sudo (admin) role
Agree
4) Others


snapshot, VNC/Spice as appropriate on the individual VM
A user should also be added the to authorized user list a resource like VM.   Kimchi will  check if the action to a resource is passed based on the authorized user list of the resource and the role granted to the user.  Metadata of the authorized user list should be stored in somewhere.
Metadata stored w/ libvirt. Only required data should be a set of group/role mappings for each VM resource.


Group/role mapping will be stored in the <metadata> element of the VM
Domain XML. If the VM is migrated to a new host, the metadata will go
with it.

VM is not the only one type of resource in Kimchi.  We do need other group/role mappings to other resources like storagepools, networks in the future.  But now, we can have non-VM specific resources hard mapped to the sudo (admin) role.
Libvirt has facility to keep metadata associated with other resources. The is one of the avenues I proposed we could extend the design in the future. For 1.2 we want to keep it simple by scoping the problem to the VMs. I am not considering sudo a role but a group. It so happens that any member of that group implicitly has the admin role for all resources, just as root on a linux host has authorization to manage any part of KVM.


*Algorithm*
Login:
    If the user is a member of the sudo (admin) group
        grant all permissions and render the full Kimchi UI as today
    else
        enumerate all the groups the user is a member of, including
groups of groups recursively
        for each VM determine the highest role available to the user by
the various groups he is a member of
        render the kimchi frame with only a list of the authorized VMs,
each with the appropriate actions
        If none, render the empty list

*Kimchi 1.2+ Extensibilty
*How can the 1.2 proposal be extended in future Kimchi versions as needed?
*    Resource **
*        Other resources (network, storage) can use the same group/role
authorization concept, relying on similar libvirt metadata for storage.
Storage for the authorization mapping would have to be elsewhere for any
resource libvirt has not defined metadata on.
*    Admin granularity*
        Additional roles can be introduced to allow some admins control
over network while others control storage pools and volumes. Storage for
these administration scoped roles would have to be defined and
replicated for future cluster support.
*Role granularity*
        Additional roles can be introduced beyond admin and user to
allow more differentiation in what actions a specific group of users can
access including custom administrator defined roles

--
Adam King <rak at linux.vnet.ibm.com>
IBM CSI


_______________________________________________
Kimchi-devel mailing list
Kimchi-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel




_______________________________________________
Kimchi-devel mailing list
Kimchi-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel


-- 
Adam King <rak@linux.vnet.ibm.com>
IBM CSI