Bug #19056
radosgw S3 AWS4 signature and keystone integration broken
0%
Description
We have an Jewel radosgw, with the s3 authentication integration with keystone enabled (rgw_s3_auth_use_keystone = true)
# radosgw-admin --version ceph version 10.2.5 (c461ee19ecbc0c5c330aca20f7392c9a00730367)
The s3 client (s3cmd) uses AWS4 signature, but the authentication to radosgw always fails: "ERROR: S3 error: 403 (InvalidAccessKeyId)"
Here below is the radosgw log file and, unlike validation for AWS2 signature, there is NO callout to keystone to resolve the access_key -> tenant_id for the given user...
2017-02-22 15:50:09.325582 7f0ec67fc700 1 ====== starting new request req=0x7f0ec67f67d0 ===== 2017-02-22 15:50:09.325623 7f0ec67fc700 2 req 65:0.000041::GET /::initializing for trans_id = tx000000000000000000041-0058adb331-145bda7-default 2017-02-22 15:50:09.325643 7f0ec67fc700 10 rgw api priority: s3=5 s3website=4 2017-02-22 15:50:09.325646 7f0ec67fc700 10 host=valery-test.os.s2.scloud.switch.ch 2017-02-22 15:50:09.325655 7f0ec67fc700 20 subdomain=valery-test domain=os.s2.scloud.switch.ch in_hosted_domain=1 in_hosted_domain_s3website=0 2017-02-22 15:50:09.325663 7f0ec67fc700 20 final domain/bucket subdomain=valery-test domain=os.s2.scloud.switch.ch in_hosted_domain=1 in_hosted_domain_s3website=0 s->info.domain=os.s2.scloud.switch.ch s->info.request_uri=/valery-test/ 2017-02-22 15:50:09.325685 7f0ec67fc700 10 meta>> HTTP_X_AMZ_CONTENT_SHA256 2017-02-22 15:50:09.325696 7f0ec67fc700 10 meta>> HTTP_X_AMZ_DATE 2017-02-22 15:50:09.325702 7f0ec67fc700 10 x>> x-amz-content-sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 2017-02-22 15:50:09.325704 7f0ec67fc700 10 x>> x-amz-date:20170222T155139Z 2017-02-22 15:50:09.325747 7f0ec67fc700 20 get_handler handler=25RGWHandler_REST_Bucket_S3 2017-02-22 15:50:09.325756 7f0ec67fc700 10 handler=25RGWHandler_REST_Bucket_S3 2017-02-22 15:50:09.325759 7f0ec67fc700 2 req 65:0.000178:s3:GET /::getting op 0 2017-02-22 15:50:09.325778 7f0ec67fc700 10 op=25RGWListBucket_ObjStore_S3 2017-02-22 15:50:09.325782 7f0ec67fc700 2 req 65:0.000200:s3:GET /:list_bucket:authorizing 2017-02-22 15:50:09.325813 7f0ec67fc700 10 v4 signature format = c535db1ceb4ed3c7eb68f2f9a35ad61849631a1bb6391dcf314f5aa7f717b3fd 2017-02-22 15:50:09.325827 7f0ec67fc700 10 v4 credential format = 0213b30621e74120b73d11a5e99240f9/20170222/US/s3/aws4_request 2017-02-22 15:50:09.325831 7f0ec67fc700 10 access key id = 0213b30621e74120b73d11a5e99240f9 2017-02-22 15:50:09.325833 7f0ec67fc700 10 credential scope = 20170222/US/s3/aws4_request 2017-02-22 15:50:09.325874 7f0ec67fc700 20 get_system_obj_state: rctx=0x7f0ec67f54c0 obj=.users:0213b30621e74120b73d11a5e99240f9 state=0x7f0e9401fc48 s->prefetch_data=0 2017-02-22 15:50:09.325896 7f0ec67fc700 10 cache get: name=.users+0213b30621e74120b73d11a5e99240f9 : type miss (requested=6, cached=0) 2017-02-22 15:50:09.327179 7f0ec67fc700 10 cache put: name=.users+0213b30621e74120b73d11a5e99240f9 info.flags=0 2017-02-22 15:50:09.327205 7f0ec67fc700 10 moving .users+0213b30621e74120b73d11a5e99240f9 to cache LRU end 2017-02-22 15:50:09.327222 7f0ec67fc700 10 error reading user info, uid=0213b30621e74120b73d11a5e99240f9 can't authenticate 2017-02-22 15:50:09.327225 7f0ec67fc700 10 failed to authorize request 2017-02-22 15:50:09.327228 7f0ec67fc700 20 handler->ERRORHANDLER: err_no=-2028 new_err_no=-2028 2017-02-22 15:50:09.327425 7f0ec67fc700 2 req 65:0.001843:s3:GET /:list_bucket:op status=0 2017-02-22 15:50:09.327440 7f0ec67fc700 2 req 65:0.001859:s3:GET /:list_bucket:http status=403 2017-02-22 15:50:09.327451 7f0ec67fc700 1 ====== req done req=0x7f0ec67f67d0 op status=0 http_status=403 ======
History
#1 Updated by Yehuda Sadeh about 7 years ago
- Assignee set to Radoslaw Zarzynski
@rzarzynski can you take a look at this one?
#2 Updated by Valery Tschopp about 7 years ago
This feature is very important to us. A lot of S3 client library and CLI support AWS4 signature by default, so the keystone integration must work.
#3 Updated by Radoslaw Zarzynski over 6 years ago
- Status changed from New to Resolved
PR: https://github.com/ceph/ceph/pull/14885. The code will be available starting from Luminous.
#4 Updated by Valery Tschopp over 6 years ago
Radoslaw Zarzynski wrote:
PR: https://github.com/ceph/ceph/pull/14885. The code will be available starting from Luminous.
Can it be backported to Jewel? We are running Jewel in our production cluster.
#5 Updated by Radoslaw Zarzynski over 6 years ago
Valery Tschopp wrote:
Can it be backported to Jewel? We are running Jewel in our production cluster.
I'm afraid the changes are too big to backport them. A separated patch for Jewel would be needed.