Open Stack

We recently finished up functional tests for the keystone integration
recently added to glance, and I wanted to send a quick description of
the specifics for everyone's reference—could give people an idea of how
to integrate with keystone for other projects.

tl;dr version: The code added to glance performs integration with
keystone, adds the concept of ownership to images, and allows images to
be shared with others.

Now, the details:

First, glance is integrated with keystone.  This requires adding a
couple of sections to the glance-api.conf and glance-registry.conf
configuration files and modifying the pipeline.  (The plugin WSGI
middleware pieces themselves are shipped with keystone.)  This
integration makes the username, tenant, and "is_admin" flag available.
There is also an abstract concept of an "owner"--by default, this is the
tenant, but a configuration option allows it to be switched to be the
user name.

The second piece is that all images now have an "owner" field (separate
from image properties).  The "owner" is based on that abstract concept
of "owner" in the glance keystone integration--i.e., by default, images
are owned by tenants, but flipping that configuration option makes them
owned by individual users.  Either way, the "owner" field of an image is
set to the "owner" abstraction of the creating user and cannot be
modified except by an admin.  Also, the "is_public" flag that was
already available for images is now interpreted relative to "owner": if
the image is owned by the authenticated user, it shows up in lists even
if is_public is False, while other users can neither see nor access the
image (with the exception of admins).  There is one special behavior I
implemented: if the owner of an image is set to nothing, the image is
always accessible, but is_public determines whether the image is visible
in lists.  The point of this special behavior is to allow providers to
publish alpha and beta images that they want some users to be able to
use, but which they don't want to appear in lists of usable images.

The third piece is image sharing.  Images can be shared to other users;
these third-party users cannot change the image, but they are able to
see and use images shared with them, and may be delegated permission to
further share images.  Again, access controls are based on the "owner"
abstraction.

Now, the really long technical details:

The "is_public" attribute already existed in images; the "owner"
attribute has been added.  It may not be changed; attempts to change
"owner" are silently ignored (I wanted to allow the possibility that
users take the image description, change a value, and PUT it back
whole).  The glance command line tool has been updated to allow admins
to manipulate "owner".

Sharing is a little more complicated.  There are a total of 5 operations
added: listing who an image has been shared with (image "members");
listing images shared with someone; adding to or updating an entry in an
image's sharing list (the image's "membership list"); replacing an
image's membership list; and deleting an entry from an image's
membership list.

Retrieving an image's membership list is a GET
to /images/{image_id}/members; the returned JSON entry looks like:

        {"members": [
                {"member_id": <MEMBER>,
                 "can_share": <SHARE_PERMISSION>},
                ...
        ]}

Likewise, retrieving the list of images shared with a given owner is a
GET to /shared-images/{member}, and the returned JSON looks like:

        {"shared_images": [
                {"image_id": <IMAGE>,
                 "can_share": <SHARE_PERMISSION>},
                ...
        ]}

The entire membership list of an image may be replaced by doing a PUT
to /images/{image_id}/members with a JSON body like the following:

        {"memberships": [
                {"member_id": <MEMBER>,
                 "can_share": <SHARE_PERMISSION>},
                ...
        ]}

(Note that the "can_share" attribute is optional here; if not provided,
old entries preserve their "can_share" setting and new entries default
to False.  Any entries not in the body will be removed.)

Finally, individual entries can be added, updated, or deleted using PUT
or DELETE requests to /images/{image_id}/members/{member}.  For the PUT
operation, the body is optional, for specifying the "can_share" setting
of the membership:

        {"member": {"can_share": <SHARE_PERMISSION>}}

If the body is not provided, existing entries have their "can_share"
setting preserved and new entries have it default to False.  Obviously,
no body can be provided when deleting an entry with the DELETE
operation.

I should note that attempting to delete an image or update image
attributes when you do not own the image will result in a 404 error,
instead of a 403 error.  The sharing operations listed above return 403,
but the way glance is currently architected makes it more difficult to
return a 403 for the image update/delete operations.  I expect this to
be addressed by future work.
-- 
Kevin L. Mitchell <kevin.mitchell at rackspace.com>

This email may include confidential information. If you received it in error, please delete it.