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 | |||
| 3 | h3. Summary |
||
| 4 | |||
| 5 | h3. Owners |
||
| 6 | |||
| 7 | * Yehuda Sadeh (Inktank) |
||
| 8 | * Name (Affiliation) |
||
| 9 | * Name |
||
| 10 | |||
| 11 | h3. Interested Parties |
||
| 12 | |||
| 13 | * Name (Affiliation) |
||
| 14 | * Name (Affiliation) |
||
| 15 | * Name |
||
| 16 | |||
| 17 | h3. Current Status |
||
| 18 | |||
| 19 | There's an open issue in the ceph tracker for this task (#3454) |
||
| 20 | |||
| 21 | h3. Detailed Description |
||
| 22 | |||
| 23 | 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 | 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 | (as we only have a single 'tenant'). |
||
| 26 | 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 | 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 | 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 | which user signed that request, we can only assume that the request's target bucket owner is the one that signed it. |
||
| 30 | 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 | model and with the swift api. |
||
| 32 | |||
| 33 | |||
| 34 | h3. Work items |
||
| 35 | |||
| 36 | h4. Coding tasks |
||
| 37 | |||
| 38 | # add temp url key to user info |
||
| 39 | # configure temp url key via radosgw-admin |
||
| 40 | # implement new api to configure temp url key (compatible with relevant swift api) |
||
| 41 | # modify swift auth to handle signed requests |
||
| 42 | # (phase 2) integrate with keystone |
||
| 43 | |||
| 44 | h4. Build / release tasks |
||
| 45 | |||
| 46 | # Task 1 |
||
| 47 | # Task 2 |
||
| 48 | # Task 3 |
||
| 49 | |||
| 50 | h4. Documentation tasks |
||
| 51 | |||
| 52 | # Task 1 |
||
| 53 | # Task 2 |
||
| 54 | # Task 3 |
||
| 55 | |||
| 56 | h4. Deprecation tasks |
||
| 57 | |||
| 58 | # Task 1 |
||
| 59 | # Task 2 |
||
| 60 | # Task 3 |