Project

General

Profile

Bug #9588

Keystone s3 auth integration lacking access_key = tenant:user ability supported by swift s3

Added by Mark Kirkwood over 9 years ago. Updated over 9 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Target version:
-
% Done:

0%

Source:
other
Tags:
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

For instance according to http://docs.openstack.org/grizzly/openstack-object-storage/admin/content/configuring-openstack-object-storage-with-s3_api.html I can use the following access/secret key setup to authenticate:

import boto
import boto.s3.connection

access_key = 'demo:demo'
secret_key = 'password'

I have tested this and it works against a swift backend (that uses keystone auth). Amending only the host in my actual connect to use an equivalant rgw and the above fails with http 403. Replacing the concatinated tenant:user with the actual ec2 access key (and similarly for the secret) works fine against rgw. It seems like we should support this.

I'm not 100% whether this a a bug or feature (not sure of the scope of swift compatibility we are reaching for here).

History

#1 Updated by Mark Kirkwood over 9 years ago

Hmm - maybe not tested enough, as it looks like the way devstack sets up the swift s3 layer is a bit screwy, and almost any garbage can go in access_key and secret_key and be authenticated. I will examine in more detail.

#2 Updated by Mark Kirkwood over 9 years ago

Despite asking for swift I am actually getting the nova object store doing the s3 stuff it seems. I'll comment gaian when I'm sure I am actually talking to swift!

#3 Updated by Mark Kirkwood over 9 years ago

So, actually talking to a swift s3 proxy with:

access_key = 'demo:demo'
secret_key = 'password'

results in:

boto.exception.S3ResponseError: S3ResponseError: 403 Forbidden

in particular:

<Error><Code>SignatureDoesNotMatch</Code><Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message><RequestId>txff940ba5951a40dea93f3-0054261c16</RequestId></Error>

which makes sense according to the way s3 protocol is supposed to work. Whereas using the key+secret from ec2-credentials works fine.

So, sorry for the confusion - looks like RGW is operating as desired in this regard, and I've merely been confused by the Openstack Swift doco!

#4 Updated by Sage Weil over 9 years ago

  • Status changed from New to Rejected

thanks Mark!

Also available in: Atom PDF