openstack team mailing list archive

[Hugo <tonytkdk@xxxxxxxxx>]

Best Regard
Hugo K.

Vishvananda Ishaya <vishvananda@xxxxxxxxx> 於 2011/3/31 6:29 寫道：

> I think authz is simplest if we just give it the responsibility of mapping subjects, verbs, and objects.
> 
> subjects are returned by authn.  They can be users/projects/roles/groups/etc, but are basically opaque
> verbs are defined by the application:
> launch_instance, get_volume, get_container, etc.
> objects are the entities that actions are performed on.
> 
> Then the authz system can just define how these three are mapped to create a pass/fail.
> 
> There can be some magic in the rules to make this much easier:
> 
> 1) the concept of an object_owner.  This allows rules to match the stuff returned by authn to an "owner" field on the object
> 
> 2) dividing groups of actions into certain "roles" or "groups" returned by authn.  The obvious one here is "admin", but other general roles could be defined as well.  I'm not sure how we validate the roles returned by an external authn server.  We don't really want Alice's admins to have full admin rights to our deploy.  Perhaps some namespacing here is necessary. alice.admin vs mydeploy.admin
> 
> Vish
> 
> On Mar 30, 2011, at 3:10 PM, Sandy Walsh wrote:
> 
>> From: Jay Pipes [jaypipes@xxxxxxxxx]
>> 
>>> Come to think of it, there's no reason that role A would need to have similar privileges in
>> zones X and Y. More likely than not, they would have different
>> privileges, and therefore a federated authz service wouldn't really
>> make sense.
>> 
>> I see your point, I was thinking at the Rights level, not Roles/Groups, and envisioning Rights like: 
>> 
>> can_boot_os=windows;linux
>> can_boot_flavor=tiny;small;medium
>> can_migrate_outside_zone=True
>> maximum_ram_size=512m
>> 
>> Certainly, we could have pre-established Rights just as we would have common Roles/groups.
>> 
>> -S
>> 
>> 
>> Confidentiality Notice: This e-mail message (including any attached or
>> embedded documents) is intended for the exclusive and confidential use of the
>> individual or entity to which this message is addressed, and unless otherwise
>> expressly indicated, is confidential and privileged information of Rackspace.
>> Any dissemination, distribution or copying of the enclosed material is prohibited.
>> If you receive this transmission in error, please notify us immediately by e-mail
>> at abuse@xxxxxxxxxxxxx, and delete the original message.
>> Your cooperation is appreciated.
>> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp