[Openstack] [Keystone] [Swift] Keystone Tenant vs Swift Account

John Dickinson john.dickinson at RACKSPACE.COM
Tue Jul 19 14:07:34 UTC 2011


Account deletes need to be handled by a DELETE call on the account to the swift cluster. This would need to be set up as some separate process in your account management system.

--John


On Jul 19, 2011, at 8:55 AM, Khandeshi, Divyesh wrote:

> Hi John,
> 
> Thanks for the quick API info. 
> 
> Going back to the lazy model for provisioning accounts, how do you handle account deletions? Essentially, the issue here is that since the account_autocreate flag only handles creation, what happens when, say, a tenant is deleted from Keystone? How does that deletion get propagated/synced to Swift? Who or how would the account tombstones be set?
> 
> Thanks
> 
> Divyesh
> 
> 
> -----Original Message-----
> From: John Dickinson [mailto:john.dickinson at rackspace.com] 
> Sent: Monday, July 18, 2011 5:03 PM
> To: Khandeshi, Divyesh
> Cc: 'openstack at lists.launchpad.net'
> Subject: Re: [Openstack] [Keystone] [Swift] Keystone Tenant vs Swift Account
> 
> The security implications are tied to what credentials as user gets from the auth server you are using. The possibility is that a user could delete their own account (or even another user's account) or create new accounts. Disabling allow_account_management eliminates these issues by disabling the functionality.
> 
> There are no formal docs of this part of the API. It's quite simple though: PUT/POST/GET/HEAD/DELETE to /v1/"your account string"
> 
> --John
> 
> 
> On Jul 18, 2011, at 3:00 PM, Khandeshi, Divyesh wrote:
> 
>> John,
>> 
>> Sorry, hit the send button too fast..
>> 
>> What are the security implications?
>> 
>> Thanks
>> 
>> Divyesh
>> 
>> -----Original Message-----
>> From: openstack-bounces+divyesh.khandeshi=hp.com at lists.launchpad.net [mailto:openstack-bounces+divyesh.khandeshi=hp.com at lists.launchpad.net] On Behalf Of Khandeshi, Divyesh
>> Sent: Monday, July 18, 2011 3:56 PM
>> To: John Dickinson
>> Cc: 'openstack at lists.launchpad.net'
>> Subject: Re: [Openstack] [Keystone] [Swift] Keystone Tenant vs Swift Account
>> 
>> John,
>> 
>> Thanks for the information. 
>> 
>> When you mention PUT/DELETE accounts - where is this API documented? Or could you provide more details for the supported methods?
>> 
>> Thanks
>> 
>> Divyesh
>> 
>> -----Original Message-----
>> From: John Dickinson [mailto:john.dickinson at rackspace.com] 
>> Sent: Monday, July 18, 2011 3:41 PM
>> To: Khandeshi, Divyesh
>> Cc: Ziad Sawalha; 'openstack at lists.launchpad.net'
>> Subject: Re: [Openstack] [Keystone] [Swift] Keystone Tenant vs Swift Account
>> 
>> To provision an account in a swift cluster without using the autocreate option, you must run a proxy server with the allow_account_management option set to True. Your auth system then needs to PUT/DELETE accounts to that proxy server as necessary. There are security implications here (which is why the value defaults to false), so you should take care to ensure that only your auth server can talk to the proxy server with this option turned on.
>> 
>> --John
>> 
>> 
>> On Jul 18, 2011, at 2:05 PM, Khandeshi, Divyesh wrote:
>> 
>>> Hi Ziad,
>>> 
>>> Thanks for your responses.
>>> 
>>> So Swift will authenticate against Keystone directly with the method you describe below? But is there an actual sync mechanism to sync keystone(tenant) -> swift(account)? account_autocreate provides the lazy option.
>>> 
>>> Sorry for repeating this (and may be Swift folks can possibly help): What API/method does Rackspace dashboard use to manage accounts in Swift? Essentially, is there any exposed API access for managing accounts in Swift (non-lazy option). The swift_auth.py appears to only handle auth cases including Swift auth but does not actually provide account management (Swift account CRUD).
>>> 
>>> Thanks
>>> 
>>> Divyesh
>>> 
>>> 
>>> From: Ziad Sawalha [mailto:ziad.sawalha at rackspace.com] 
>>> Sent: Monday, July 18, 2011 11:41 AM
>>> To: Khandeshi, Divyesh; 'openstack at lists.launchpad.net'
>>> Subject: Re: [Openstack] [Keystone] [Swift] Keystone Tenant vs Swift Account
>>> 
>>> Hi Divyesh - additional info I just got:
>>> 
>>> "run with account_autocreate = True. As long as account ids == tenant names, you should be fine.  For example, if you request /v1.0/AUTH_foobar and you have the foobar tenant then it will try to authorize against the foobar tenant."
>>> 
>>> Z
>>> 
>>> From: "Khandeshi, Divyesh" <divyesh.khandeshi at hp.com>
>>> Date: Mon, 18 Jul 2011 15:47:31 +0100
>>> To: Ziad Sawalha <ziad.sawalha at rackspace.com>, "'openstack at lists.launchpad.net'" <openstack at lists.launchpad.net>
>>> Subject: RE: [Openstack] [Keystone] [Swift] Keystone Tenant vs Swift Account
>>> 
>>> Ziad,
>>> 
>>> 1.  You mention that Nova has a shim for lazy syncing of accounts with Keystone. What about Swift? Or the account_autocreate (in proxy-server.conf) the only option to achieve this?
>>> 2.  As to the Rackspace dashboard, what API does it use for provisioning? Is it a Rackspace-only API or some undocumented/unexposed Account management API in Swift?
>>> 
>>> Thanks
>>> 
>>> Divyesh
>>> 
>>> 
>>> From: openstack-bounces+divyesh.khandeshi=hp.com at lists.launchpad.net [mailto:openstack-bounces+divyesh.khandeshi=hp.com at lists.launchpad.net] On Behalf Of Ziad Sawalha
>>> Sent: Saturday, July 16, 2011 3:30 PM
>>> To: Nguyen, Liem Manh; 'openstack at lists.launchpad.net'
>>> Subject: Re: [Openstack] [Keystone] [Swift] Keystone Tenant vs Swift Account
>>> 
>>> Swift account and tenant should be the same. This does not prescribe that Swift not store them locally (Nova still stores projects).
>>> 
>>> The synchronization can be lazy (Nova does this with a shim in Keystone. If a request is authorized by Keystone on a tenant that does not have a corresponding project, it creates it right there and then). Or it can be proactive (as opposed to lazy).
>>> 
>>> For proactive provisioning (where accounts would be synched to swift when they are created.
>>> 
>>> Summarizing:
>>> Lazy provisioning: Users and tenants are created as authenticated requests come in to the openstack service for the first time.
>>> Proactive provisioning: Users and tenants are created in all services as they are created in Keystone.
>>> ,Ote: my personal preference is for lazy provisioning.
>>> 
>>> For proactive provisioning, we would need a service to own orchestration (or provisioning or order fullfilment - pick your model). We don't have one today. The Dashboard does some of that. Rackspace does it using non-openstack components which contain Rackspace business logic.
>>> Will this ever become an OpenStack project or wiL this always live in the business systems of the operator (an enterprise deploying and operating openstack)...
>>> 
>>> Z
>>> 
>>> From: Nguyen, Liem Manh [mailto:liem_m_nguyen at hp.com] 
>>> Sent: Friday, July 15, 2011 05:56 PM
>>> To: openstack at lists.launchpad.net <openstack at lists.launchpad.net> 
>>> Subject: [Openstack] [Keystone] [Swift] Keystone Tenant vs Swift Account 
>>> 
>>> Hi,
>>> 
>>> For Nova, the Keystone Tenant maps to a Nova project, and according to the "Finalize Auth integration" blueprint, the Nova project is going away ("no more project/roleuser info in nova"). 
>>> 
>>> What about Swift's account?  I assume the Keystone tenant would map to a Swift account.  How would this mapping occur?  Would Swift still maintain account information in the db and these will get synchronized with Keystone tenant information (i.e., auto-create accounts), or would Swift get rid of the account concept and have a mapping between tenant and containers instead?  If there is any existing blue-print/docs on Keystone/Swift integration plan for Diablo, that would be greatly appreciated.
>>> 
>>> Thanks,
>>> Liem
>>> This email may include confidential information. If you received it in error, please delete it.
>>> 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
>> 
>> 
>> _______________________________________________
>> 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
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110719/237c2b57/attachment.bin>


More information about the Openstack mailing list