[Openstack] Swift S3 with Keystone anyone?

Akira Yoshiyama akirayoshiyama at gmail.com
Thu Feb 23 14:50:07 UTC 2012


Hi all,

My co-worker built swift e3 environment (thank you Eguchi-san), so I checked
my patch and fix it. Then, I checked the last s3_token.py and swift3.py. I found
two problems.

a) swift3 sets HTTP_X_AUTH_TOKEN (= X-Auth-Token?) in constructors
    of ServiceController, BucketController and ObjectController with base64ed
    canonical_string(req). I think it's NOT necessary when s3_token already sets
    X-Auth-Token header.

b) swift3 gets account information from Authorization header (I'm sorry that
    I called it 'Signature' header) but it's an EC2 access key. I
think it's better to
   create a new header for account information to pass it to swift3, but it's a
   solution to rewrite Authorization header in s3_token.py like below:

diff --git a/keystone/middleware/s3_token.py b/keystone/middleware/s3_token.py
index 8cf3e0a..f8c6a14 100644
--- a/keystone/middleware/s3_token.py
+++ b/keystone/middleware/s3_token.py
@@ -122,6 +122,7 @@ class S3Token(object):
             raise

         req.headers['X-Auth-Token'] = token_id
+        req.headers['Authorization'] = 'AUTH_%s:dummy' % tenant[0]
         environ['PATH_INFO'] = environ['PATH_INFO'].replace(
                 account, 'AUTH_%s' % tenant[0])
         return self.app(environ, start_response)

p.s.
One more thing. Swift3.py returns illegal status for request to nonexistent
buckets, so euca-upload-bundle will fail when uploading some files to a new
bucket. I'm using euca-upload-bundle for keystoned swift with a patch below:

diff -u swift3.py ~/swift3.py
--- swift3.py   2012-02-23 21:40:10.000000000 +0900
+++ /root/swift3.py     2012-02-23 22:28:22.000000000 +0900
@@ -240,7 +240,7 @@
             if status == 401:
                 return get_err_response('AccessDenied')
             elif status == 404:
-                return get_err_response('InvalidBucketName')
+                return get_err_response('NoSuchBucket')
             else:
                 return get_err_response('InvalidURI')

@@ -311,7 +311,7 @@
             if status == 401:
                 return get_err_response('AccessDenied')
             elif status == 404:
-                return get_err_response('InvalidBucketName')
+                return get_err_response('NoSuchBucket')
             elif status == 409:
                 return get_err_response('BucketNotEmpty')
             else:

Best regards,
Akira YOSHIYAMA <akirayoshiyama at gmail.com>


2012年2月19日10:20 Akira Yoshiyama <akirayoshiyama at gmail.com>:
> Hi all,
>
> I'm sorry for my previous post.
>
> Thank you Pete for your work. I think your s3token middleware have
> to modify the S3 Signature header
> from
>     Signature: <EC2ACCESSKEY>:<signaturehash>
> to
>     Signature: <USERID>:<anything>
>
> for swift3 middleware without my original patch for it.
>
> And I'm sorry about my late. Unfortunately, I'm not a programmer of OpenStack
> but an OSS system engineer, so I don't have enough time to develop
> OpenStack.
>
> Best regards,
> Akira Yoshiyama
>
> 2012/2/19 Akira Yoshiyama <akirayoshiyama at gmail.com>:
>> Hi,
>>
>> 2012/02/18 0:36 "Chmouel Boudjnah" <chmouel at chmouel.com>:
>>>
>>> On 17 Feb 2012, at 06:12, Pete Zaitcev wrote:
>>>
>>> - A S3Token middleware which is based on Akira version with some fixes.
>>>
>>> Yeah, that looks beautiful... Unfortunately the back-end
>>> inherits the old problem: it authorizes against EC2 credentials
>>> instead of Swift credentials. The result is, if two applications
>>> A and B use different access methods, CF and S3, to the same account,
>>> they do not see each other's objects. It happens because the storage
>>> URL returned by Keystone differs for them, as far as I can discern.
>>>
>>>
>>> This is actually supported as mentioned in my temporary doc[1]  see the
>>> transcript here :
>>>
>>> http://pastie.org/3401911
>>>
>>> this made of from a fresh devstack with a few tweaks to the
>>> configurations.
>>> I plan to add this to devstack but  I am waiting first for some of my
>>> other review to get approved to push those changes and be able to get rid of
>>> swift-keystone2 for good.
>>>
>>> S3token middleware: https://review.openstack.org/#change,3910
>>>
>>> Swift token middleware: https://review.openstack.org/#change,3911
>>>
>>> Do you still want reviews on these, after the merge of redux?
>>>
>>>
>>> This has been merged to keystone master, feel free to review the one the
>>> add reseller admin support :
>>>
>>> https://review.openstack.org/#change,4234
>>>
>>> and the doc update :
>>>
>>> https://review.openstack.org/#change,4233
>>>
>>> The reseller admin will allow us ultimately to have swift acting as a
>>> nova-objectstore for nova.
>>>
>>> I have more plans for the middleware, I'd like to get the compressive
>>> tempauth testsuite running on swiftauth  with almost no modifications and
>>> add along the way anonymous user object access via ACL.
>>>
>>> Let me know if you have questions.
>>>
>>> Cheers,
>>> Chmouel.
>>>
>>> PS: readding openstack@ as this may be useful for everyone.
>>>
>>> [1] http://p.chmouel.com/swift-keystonelight-s3.txt
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>
>
>
> --
> 吉山あきら <akirayoshiyama at gmail.com>



-- 
吉山あきら <akirayoshiyama at gmail.com>




More information about the Openstack mailing list