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: [email protected] > [mailto:[email protected]] On > Behalf Of Khandeshi, Divyesh > Sent: Monday, July 18, 2011 3:56 PM > To: John Dickinson > Cc: '[email protected]' > 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:[email protected]] > Sent: Monday, July 18, 2011 3:41 PM > To: Khandeshi, Divyesh > Cc: Ziad Sawalha; '[email protected]' > 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:[email protected]] >> Sent: Monday, July 18, 2011 11:41 AM >> To: Khandeshi, Divyesh; '[email protected]' >> 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" <[email protected]> >> Date: Mon, 18 Jul 2011 15:47:31 +0100 >> To: Ziad Sawalha <[email protected]>, >> "'[email protected]'" <[email protected]> >> 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: [email protected] >> [mailto:[email protected]] On >> Behalf Of Ziad Sawalha >> Sent: Saturday, July 16, 2011 3:30 PM >> To: Nguyen, Liem Manh; '[email protected]' >> 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:[email protected]] >> Sent: Friday, July 15, 2011 05:56 PM >> To: [email protected] <[email protected]> >> 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 : [email protected] >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
