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.
