The embedded image was garbled, so I have attached a link to the image. Somik
On Fri, Aug 19, 2011 at 2:36 PM, Somik Behera <so...@nicira.com> wrote: > Hello All, > > I spent some time on and offline with Nova, Swift & Keystone PTLs > understanding current Keystone use-cases and championing the fine-grained > AuthZ that Quantum will need, here is the summary outcome from those > discussions. Before I dive into that, I would like say the bulk of our AuthN > & AuthZ concerns are already being handled by Salvatore's branch! So, Thanks > Salvatore! > These discussions were along the lines of providing AuthZ of "interfaces" > owned by Nova or (in the future) other interface services. > > *Current Status of AuthZ, wrt Keystone implementation:* > > Keystone is a young( just incubated) project that is focused on addressing > existing use-cases, mostly around AuthN. A notion of "roles" was added as > groups and roles exist in Active Directory and LDAP systems, and Nova > already had some notion of "roles." Keystone is an "integration" service, > that means that Keystone has plugins in the backend to implement Keystone > concepts using Active Directory and other such identity management > solutions. Similar to the notion of Quantum "plugins" > > Roles in Keystone are high-level roles that map to job roles and are > applied on a particular user, for a particular tenant. But the enforcement > of the "role" is left to the individual service, Keystone only provides the > role that a particular user owns, and its the responsibility of the > individual service( Nova, Quantum) to enforce that role. This model of AuthZ > is consistent with the way FileSystems managing a large number of objects > enforce AuthZ where the ACLs are stored with individual files, not in a > separate centralized directory. > > With that said, Keystone team is interested in exploring our use case where > AuthZ is either enforced or orchestrated by Keystone across multiple > underlying services and this would be a good thing to discuss during the > Essex Design Summit. > > *Options for achieving AuthZ in Quantum during diablo time-frame: > ** > Option 1: Short-term solution -** *Introduce a role named "NetworkAdmin" > or "Quantum:NetworkAdmin" This new roles has to be owned by any user > wishing to perform VIF plug operations. The thinking is that the > "NetworkAdmin" role is allocated to the service provider and for the time > being, only the service provider can actually perform "VIF plugging." So, we > have multi-tenancy in our AuthZ APIs for reading and creating network > topologies but not for plugging VIFs. Not quite where we want to be, but it > does provide a realistic Quantum deployment solution in diablo time-frame. > > *Option 2: Medium-term solution* - Quantum performs AuthZ for Network > resources, and calls into Nova to perform network interface AuthZ, and then > performs the VIF plugging. This solution is not ideal and only medium term > as this architecture requires Quantum to contain clients of various > "interface" services, of which Nova is the first interface service. > > The sequence of calls would look someting like this: > > http://www.websequencediagrams.com/index.php?img=mscb96q6O > *Option 3: Long-term solution* - Quantum calls into Keystone for AuthZ and > asks Keystone "Does UserA have VIF-Plug privilege on Tenant-X?" Keystone > either maintain a central repository to service such a request or proxies > the request to individual service, i.e. Nova in this case, in order to > fulfill such a request. This solution needs additional discussion with the > Keystone team. > > > *Summary:* In summary, I would in favor of just having support for Option > 1 in the current diablo time-frame and then we continue to work on more > sophisticated AuthZ solutions. One thing to note is our initial suggestion > of overloading Keystone "roles" to contain information regarding VIF-Plug, > i.e. a role like "nova:VIF-Plug-instance-0000012-eth0" associated with every > user for every VIF the user is allowed to "plug", was rejected as Keystone > implementations are backed by Active Directory and LDAP systems, which are > not designed for such fine-grained AuthZ and the associated scalability > requirements. > > Thanks, > Somik > > ---------- Forwarded message ---------- > From: Ziad Sawalha <ziad.sawa...@rackspace.com> > Date: Thu, Aug 18, 2011 at 6:00 PM > Subject: Re: [Openstack] AuthZ functionality in Keystone - Re: > [WAS]OpenStack Identity: Keystone API Proposal > To: Vishvananda Ishaya <vishvana...@gmail.com>, Somik Behera < > so...@nicira.com> > Cc: "openst...@lists.launchpad.net" <openst...@lists.launchpad.net> > > > Agreed. My suggestion (in a direct email to Jan) was: > > 1. A tenant (Tenant-X) has resources in Nova (VM1) > GET nova/Tenant-X/servers/VM1 returns {name: VM1, interface: > instance-0001-eth0 } > > 2. A user (john) creates a network in Quantum (or in Nova? Or in Quantum > through Nova?) > POST nova/Tenant-X/networks returns {name: Network-A} > Or > POST quantum/Tenant-X/networks returns {name: Network-A} > > > Here, Quantum should store the network under the tenant (although > you may > choose to track that in some other way). > > 3. Per your use case below: > 2.1 OK > 2.2 This would need a call to Nova. Only Nova knows whether > instance-0001-eth0 belongs to Tenant-X > GET > nova/tenants/Tenant-X/servers/VM1/interfaces/instance-0001-eth0 > returns 200 > 2.3 Who creates the role "plug_virtual_interface"? It sounds like > this > should be a role created by Quantum (therefore > "quantum:plug_virtual_interface") and the user should have that role on > that tenant > GET or HEAD > keystone/tenants/Tenant-X/users/john/roles/quantum:plug_virtual_interface > returns 200 > > I would not advocate creating a role for each resource. Such fine-grained > authz should probably live in the service (and not in Keystone at least > not today) > > Z > > > > > On 8/18/11 5:50 PM, "Vishvananda Ishaya" <vishvana...@gmail.com> wrote: > > > > >On Aug 18, 2011, at 3:45 PM, Somik Behera wrote: > > > >> Hi Vish, > >> > >> That would be one very reasonable way to do it, but in that case we are > >>fragmenting AuthZ in multiple services instead of Keystone taking care > >>of AuthZ across all services. > > > >We can't necessarily depend on keystone to keep track of all objects > >owned by each service. Especially for things like swift where millions > >of objects are involved. I therefore think the right solution is to have > >the services responsible for their own objects, and allow them to > >delegate to keystone in the cases where it makes sense. > > > >> > >> Depending on Keystone's roadmap and plans, we could take a 2 phased > >>approach, where Nova doing AuthZ is a temporary solution till Keystone > >>can do it or if Keystone is not going to have this capability, then we > >>go down the path you are suggesting - Keystone does AuthN and we rely on > >>Nova to authorize a tenant's access rights to a particular vif. > >> > >> Thanks, > >> Somik > > This email may include confidential information. If you received it in > error, please delete it. > > > > > -- > Somik Behera | Nicira Networks, Inc. | so...@nicira.com<sbeh...@nicira.com> | > office: 650-390-6790 | cell: 512-577-6645 > -- Somik Behera | Nicira Networks, Inc. | so...@nicira.com <sbeh...@nicira.com> | office: 650-390-6790 | cell: 512-577-6645
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
