On Tue, Dec 6, 2011 at 1:06 PM, Somik Behera <so...@nicira.com> wrote:
> Hello Netstackers, > > I have the initial blueprint and associated design wiki available for > AuthZ in Quantum. I have proposed to implement a simplistic first step > AuthZ capability in Quantum leveraging Keystone tokens and roles. > > Blueprint -- > https://blueprints.launchpad.net/quantum/+spec/authorization-support-for-quantum > Design wiki -- http://wiki.openstack.org/QuantumAuthZ > Hi Somik, Thanks for putting this together. A big part of Quantum's value is giving tenants the ability to define network topologies via the API, so I see adding authz is one of the things I think we MUST do in the Essex timeframe. So my understanding of what your proposing is: create a pretty simple Authz model that is compatible with QuantumManager. Customer can create networks, and these networks will be seen by QuantumManager, who actually does the work of creating ports + attaching interfaces. Because QuantumManager is the only entity creating ports + attaching VIFs, we make these actions "super-user" actions. This simplifies things because we don't need to authenticate vif attachments, since the "super user" is implicitly trusted. There are two tenant roles, one who can create/delete networks for the tenant, and another that can only read networks (with the point that they could understand the topology they get, or use those networks with the os-create-server extension). If so, I think this makes sense as a first cut at authz and fits with the flow we outlined at the Essex summit and will finally let us leverage keystone, which is great. Some more comments below. - It would be helpful if the "New Keystone roles for Quantum" section more explicitly called out what API calls where allowed, including both the URL and the METHOD. - It seems like you propose letting a TenantAdmin and TenantUser read ports, so they can see the current topology. I think this makes sense. Does your design propose that TenantAdmin has the ability to create/modify/delete ports (other than the attachment)? I'm not sure there is really a point to doing so, and doing so prevents the cloud operator from being able to apply a policy on the port that a tenant cannot override. What are your thoughts here? - Do you expect that Quantum authz would be enabled or disabled by default? What does nova/glance do? Would this be enabled/disabled by editing the wsgi pipeline directly? - when naming things and structuring the code, we should keep in mind that we'll likely end up introducing more advanced authz mechanism in the future. If possible, it would be good to separate generic authz from code that implements this exact authz logic (at least I'm guessing there will be some common code). - tenant admin won't actually be able to delete a network if there are still VMs on it, since Quantum API (I believe) refuses to delete a network if it has ports (is is it just attached ports?), and the tenant-admin doesn't have permission to detach or delete ports. I don't really think this is a major issue, but I thought I would mention it. - I assume "global shared" tenant id would commonly be the same value that the tenant sets for the "quantum_default_tenant_id" flag in Nova, is that correct? If so, would probably be good to have the same default and the same terminology. - What does this mean in terms of changes to the Quantum client code in Nova + Dashboard. I imagine we need some additional flags to set there to include a keystone auth credential so that client can get the appropriate keystone token? Do we have an issue covering this work? Dan > > Thanks, > Somik > > -- > 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 > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
