[Kimchi-devel] [RFC] Authorization enhancement
Shu Ming
shuming at linux.vnet.ibm.com
Tue Jan 28 04:53:38 UTC 2014
? 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ò?fa-n )
> STSM, SCEM Open Hypervisor
> IBM Linux Technology Center
> US: fnovak at us.ibm.com ; Notes: Frank Novak/Watson/IBM @IBMUS
> cell : 919-671-7966
> -------------------------------------------------------------------------------------------------------------------------
> *Adam King*_rak at linux.vnet.ibm.com _
> <mailto:kimchi-devel%40ovirt.org?Subject=Re:%20Re%3A%20%5BKimchi-devel%5D%20%5BRFC%5D%20Authorization%20enhancement&In-Reply-To=%3C52DF212B.20904%40linux.vnet.ibm.com%3E>/
> Tue Jan 21 20:38:51 EST 2014/
>
> * Previous message: _[Kimchi-devel] [RFC] Authorization enhancement
> _
> <http://lists.ovirt.org/pipermail/kimchi-devel/2014-January/001525.html>
>
> * Next message: _[Kimchi-devel] [PATCH V6] Add nfs server and target
> UI in create storage pool _
> <http://lists.ovirt.org/pipermail/kimchi-devel/2014-January/001219.html>
>
> * *Messages sorted by:*_[ date ]_
> <http://lists.ovirt.org/pipermail/kimchi-devel/2014-January/date.html#1571>_[
> thread ]_
> <http://lists.ovirt.org/pipermail/kimchi-devel/2014-January/thread.html#1571>_[
> subject ]_
> <http://lists.ovirt.org/pipermail/kimchi-devel/2014-January/subject.html#1571>_[
> author ]_
> <http://lists.ovirt.org/pipermail/kimchi-devel/2014-January/author.html#1571>
>
> ------------------------------------------------------------------------
>
> 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.
> 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
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
>
>
> *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
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.
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
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
2) VM "create", "destroy", "update" privilege also belongs to the sudo
(admin) role
3) Template "create", "destroy", "update" also belongs to the sudo
(admin) role
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.
>
> 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.
>
> *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_
> <http://lists.ovirt.org/mailman/listinfo/kimchi-devel>>
> IBM CSI
>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140128/8a07a306/attachment.html>
More information about the Kimchi-devel
mailing list