Project

General

Profile

Rgw support for swift temp url

Summary

Owners

  • Yehuda Sadeh (Inktank)
  • Name (Affiliation)
  • Name

Interested Parties

  • Name (Affiliation)
  • Name (Affiliation)
  • Name

Current Status

There's an open issue in the ceph tracker for this task (#3454)

Detailed Description

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).
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
(as we only have a single 'tenant').
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
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
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
which user signed that request, we can only assume that the request's target bucket owner is the one that signed it.
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
model and with the swift api.

Work items

Coding tasks

  1. add temp url key to user info
  2. configure temp url key via radosgw-admin
  3. implement new api to configure temp url key (compatible with relevant swift api)
  4. modify swift auth to handle signed requests
  5. (phase 2) integrate with keystone

Build / release tasks

  1. Task 1
  2. Task 2
  3. Task 3

Documentation tasks

  1. Task 1
  2. Task 2
  3. Task 3

Deprecation tasks

  1. Task 1
  2. Task 2
  3. Task 3