Open Stack

Hi Ziad,

Apologies for reviving this old thread, I am changing the subject so that my
email doesn't get lost in this big pile.

We are working on integrating Quantum Network Service with Keystone as the
AuthN/Z service provider. I believe you are aware of the prior discussion
between you, Salvatore and Vish regarding Keystone's capabilities and
Quantum's AuthN/Z use cases.

To recap prior emails, Quantum plans to leverage Keystone for AuthN
services, this is simple enough, well understood use case, for which
Keystone provides good support. The point of contention has been around
Quantum's AuthZ use case.

Quantum's AuthZ use case:

1) A tenant named Tenant-X( or user with access to Tenant-X) requests that
Network-A be created - simple enough, Keystone does AuthN and Quantum
associates the particular network with a specific tenant (Tenant-X)

2) Tenant-X( or user with access to Tenant-X) requests that Nova plug a
Virtual Network Interface named "instance-0001-eth0" into Network-A

    2.1) Quantum needs to ensure Tenant-X( or user with access to Tenant-X)
owns Network-A - Simple enough, since this network was created in Quantum,
Quantum tracks which tenant owns which Quantum resources.
    2.2) Quantum needs to ensure Tenant-X( or user with access to Tenant-X)
owns Virtual Network Interface named "instance-0001-eth0" available in Nova
- *This is where we need AuthZ help from Keystone*
    2.3) Quantum needs to ensure Tenant-X( or user with access to Tenant-X)
is authorized to perform the "plug_virtual_interface()" operation.

To solve Quantum's AuthZ use-cases as specified in section 2.2 & 2.3, we
have one possible solution using "roles", as was described by you and Vish
earlier in the original Keystone API email thread.

Solution:

1) For every token, that spins up a new VM, on VM and Virtual network
interface creation, Nova adds a "role" to the particular tenant( or token?)
with the following pattern - nova:plug_vif:<virtual interface id>
2) Quantum queries Keystone for roles associated with a particular token(
tenant/user) and can then verify if the particular user has authorization
over a virtual interface and if the user can perform "plug_vif" operation.

My question to Keystone devs is:

1) Do you guys see the proposed solution to be compatible with Keystone
Diablo API?
2) Would you recommend any other solution to Quantum's use-cases based on
the Keystone API available in Diablo time-frame.
3) If we implement the above mentioned solution, then we might easily end up
with 1 additional role for every virtual interface in Nova, this can easily
amount 1000's of roles associated with every tenant as its not unheard of
for a Virtual Machine to have 3-4 Virtual Interfaces, and now with multi-nic
support, we might see that in OpenStack too.

    - Having, for example, 3000 roles per tenant, and having a 1000 tenants
would be a reasonable estimate for a medium sized deployment. In such a
scenario, will Keystone be able to scale and operate?, do we have any
estimates or validation on Keystone's scale numbers?

    - If this doesn't work today, what are the limits of the system today?

    - If Quantum's AuthZ use case cannot be fulfilled with what Keystone API
offers in Diablo time-frame, would you know what are the future plans around
AuthZ that will help fulfill Quantum's use-cases while not imposing
scalability restrictions.


Thanks in advance for parsing through this long email and we will look
forward to your recommendations.

Regards,

Somik

On Thu, Jul 21, 2011 at 11:51 AM, Ziad Sawalha
<ziad.sawalha at rackspace.com>wrote:

>  Hot, Texas summer regards to all!
>
>  Since my last note we have had much progress on Keystone. Particularly:
>
>    - We now have Nova, Dashboard, Glance, and Keystone integration (
>    https://github.com/cloudbuilders/deploy.sh
>    - We've done some work on Swift integration (
>    https://github.com/rackspace/keystone/blob/master/keystone/middleware/swift_auth.py
>    )
>    - LDAP an be your backend (
>    https://github.com/rackspace/keystone/pull/102)
>    - We're incubating! Keystone is now officially an OpenStack Incubation
>    project.
>    - And many other updates, enhanced testing, stability improvements,
>    etc…
>
> In my last note I called out our latest API proposal and asked for input.
> We've received much of that input – thank you - and have four new blueprints
> to change the API. These are:
>
>    1. Support Service Registration (blueprint here
>    https://blueprints.launchpad.net/keystone/+spec/keystone-service-registration
>    ).
>    2. Remove support for 'default' tenant. Instead, a 'Member' or
>    'default' role can be used to manage a default tenant (this may be
>    implemented in the legacy_token_auth front end (blueprint here:
>    https://blueprints.launchpad.net/keystone/+spec/remove-default-tenant
>    ).
>    3. Support for EC2 API and non-password credentials (blueprint here:
>    https://blueprints.launchpad.net/keystone/+spec/support-multiple-credentials
>    ).
>    4. Support for API versioning in the service catalog (blueprint here:
>    https://blueprints.launchpad.net/keystone/+spec/service-catalog-version-support
>    ).
>
>  I'd like to invite comments on those blueprints (here, by email, or on
> the whiteboards or on the keystone issues list on github. Use the medium you
> prefer). As well as any new blueprint proposals to change the API.
>
>  I'd also like to propose a date for locking down the 2.0 API for Diablo.
> We're going to need some time to finish the implementation by feature freeze
> (Sept 10th), so I'd like to open the debate up for about three weeks and
> propose we lock down the API by the end of the weekend of *August 14th*.
>
> Give us your requirements… and let me know if the dates don't work for you
> or your projects/teams.
>
>  Best,
>
>  Ziad
>
>
>   From: Ziad Sawalha <ziad.sawalha at rackspace.com>
> Date: Fri, 10 Jun 2011 18:24:21 -0500
> To: "openstack at lists.launchpad.net" <openstack at lists.launchpad.net>
> Subject: OpenStack Identity: Keystone API Proposal
>
>   Time flies! It's June 10th already. In my last email to this community I
> had proposed today as the day to lock down the Keystone API so we can
> finalize implementation by Diablo-D2 (June 30th).
>
>  We've been working on this feverishly over the past couple of weeks and
> have just pushed out a proposed API here:
> https://github.com/rackspace/keystone/raw/master/keystone/content/identitydevguide.pdf
>
>  For any and all interested, the original source and code is on Github (
> https://github.com/rackspace/keystone<https://github.com/rackspace/keystone/raw/master/keystone/content/identitydevguide.pdf>),
> along with the current implementation of Keystone, examples, sample data,
> tests, instructions, and all the goodies we could muster to put together.
> The project also lives on Launchpad at http://launchpad.net/keystone.
>
>  The API we just put out there is still a proposal. We're going to be
> focusing on the implementation, but would still love to get community input,
> feedback, and participation.
>
>  Have a great weekend and regards to all,
>
>  Ziad
>
>
>
>
>   This email may include confidential information. If you received it in
> error, please delete it.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Somik Behera | Nicira Networks, Inc. | somik at nicira.com <sbehera at nicira.com> |
office: 650-390-6790 | cell: 512-577-6645
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110818/a343b627/attachment.html>