Juno Design Summit has ended
Back To Schedule
Friday, May 16 • 4:50pm - 5:30pm
Glance/Cinder usage of Swift as backing store

Sign up or log in to save this to your schedule, view media, leave feedback and see who's attending!

Glance can use Swift as backing store in one of two ways:

- Dedicated Glance account. In this mode, all images belonging to all users are stored in a single Swift account. User's do not access the account.

- User's account. In this mode, a user's images are stored in the user's account. When Glance needs to store an image, it creates a containers for the image. Cinder operates in a similar way.

There are usability and consistency problems with the User's account model. From a usability point of view, the user sees oddly named containers when they list their account. The consistency issue is more serious -- the user can delete one of these containers. However, this invalidates Glances's image database -- effectively corrupting it.

The proposed solution is as follows. (Note: the solution is described in Keystone terms, but similar solution could be devised for tempauth).

User accounts are named AUTH_. For example, for tenant/project 1234, the path is /v1/AUTH_1234. It is proposed that Glance use a path such as _ (for example, /v1/GLANCE_1234).

The sequence (and validation steps) to access the GLANCE path is as follows:

- User authenticates in usual way for the 1234 tenant/project. The user now has a token, "token U", scoped to the 1234 tenant/project. The Admin (aka swiftoperator) role is associated with the user for tenant/project 1234.

- Use presents this token in a call to the Glance API. (so far no change to normal process)

- Glance determines that it needs to access the GLANCE_1234 account. It authenticates itself as the "glance" user; not scoped to any particular tenant/project. It gets a token, "token G", with a special role. The role name is something such as "privileged-service"

- Glance performs a Swift request on the /v1/GLANCE_1234 account. The X-Auth-Token header list both "token U" *and* "token G".

- The auth_token middleware validates both tokens -- and combines the roles of both. So now the request has role "Admin" and "privileged-service". In keystoneauth, the "Admin" role is used to allow access to /v1/*_1234 and the "privileged-service" role is used to allow access to /v1/GLANCE_*.

The end user is not aware that the GLANCE_1234 account exists. An attempt to access /v1/GLANCE_1234 will will fail because "Admin" allows access to/v1/AUTH_1234, not /v1/GLANCE_1234.

Similarly, the Glance system credentials by themselves cannot be used to modify /v1/GLANCE_1234 (because the "Admin" role is missing). However, an additional feature that gave the "privileged-service" role read-only access to all GLANCE_* accounts would allow Glance to audit it's database.

A similar scheme can be used by the Cinder service.

(Session proposed by Donagh McCabe)

Friday May 16, 2014 4:50pm - 5:30pm EDT

Attendees (0)