Project

General

Profile

Rgw support for swift temp url » History » Version 1

Jessica Mack, 06/22/2015 12:48 AM

1 1 Jessica Mack
h1. Rgw support for swift temp url
2 1 Jessica Mack
3 1 Jessica Mack
h3. Summary
4 1 Jessica Mack
 
5 1 Jessica Mack
h3. Owners
6 1 Jessica Mack
7 1 Jessica Mack
* Yehuda Sadeh (Inktank)
8 1 Jessica Mack
* Name (Affiliation)
9 1 Jessica Mack
* Name
10 1 Jessica Mack
11 1 Jessica Mack
h3. Interested Parties
12 1 Jessica Mack
13 1 Jessica Mack
* Name (Affiliation)
14 1 Jessica Mack
* Name (Affiliation)
15 1 Jessica Mack
* Name
16 1 Jessica Mack
17 1 Jessica Mack
h3. Current Status
18 1 Jessica Mack
19 1 Jessica Mack
There's an open issue in the ceph tracker for this task (#3454)
20 1 Jessica Mack
21 1 Jessica Mack
h3. Detailed Description
22 1 Jessica Mack
23 1 Jessica Mack
The temp url api is being used by swift to provide a mechanism that is similar (although not identical) to the S3 pre-authenticated urls. It is achieved by (in swift) setting a temp url key on the tenant, and using it to sign specific urls (e.g., http method + path to object + timestamp).
24 1 Jessica Mack
Swift uses a different user model than the one that we're using. In swift you'd set a temp url key on the tenant, which means that you'd have one such key per tenant. We, otoh, use the S3 data / user model, and it'd make most sense (I think) to have the temp url key per user
25 1 Jessica Mack
(as we only have a single 'tenant').
26 1 Jessica Mack
Given that the api itself is built for the swift-tenant model, a user will try to access the tenant's data using the temp url, but the request itself will only include the signature, and not the effective user for which we want the request to run under. A request that is
27 1 Jessica Mack
correctly signed by the temp url key can provide access to a specific resource under that tenant. We can't (and shouldn't) do that, as our
28 1 Jessica Mack
users don't have a flat view of the entire tenant (each user has its own buckets). Now, since the api does not provide a way to specify
29 1 Jessica Mack
which user signed that request, we can only assume that the request's target bucket owner is the one that signed it.
30 1 Jessica Mack
In short: we can only have a user sign urls for buckets that it owns. I think it's a good-enough solution that is in line with our data
31 1 Jessica Mack
model and with the swift api.
32 1 Jessica Mack
 
33 1 Jessica Mack
 
34 1 Jessica Mack
h3. Work items
35 1 Jessica Mack
36 1 Jessica Mack
h4. Coding tasks
37 1 Jessica Mack
38 1 Jessica Mack
# add temp url key to user info
39 1 Jessica Mack
# configure temp url key via radosgw-admin
40 1 Jessica Mack
# implement new api to configure temp url key (compatible with relevant swift api)
41 1 Jessica Mack
# modify swift auth to handle signed requests
42 1 Jessica Mack
# (phase 2) integrate with keystone
43 1 Jessica Mack
44 1 Jessica Mack
h4. Build / release tasks
45 1 Jessica Mack
46 1 Jessica Mack
# Task 1
47 1 Jessica Mack
# Task 2
48 1 Jessica Mack
# Task 3
49 1 Jessica Mack
50 1 Jessica Mack
h4. Documentation tasks
51 1 Jessica Mack
52 1 Jessica Mack
# Task 1
53 1 Jessica Mack
# Task 2
54 1 Jessica Mack
# Task 3
55 1 Jessica Mack
56 1 Jessica Mack
h4. Deprecation tasks
57 1 Jessica Mack
58 1 Jessica Mack
# Task 1
59 1 Jessica Mack
# Task 2
60 1 Jessica Mack
# Task 3