Glance-property-protections-product

WTF?

So I've been reading Chris Vander Mey's "Shipping Greatness" and got to the part where he recommends doing the press release and feature FAQ before coding starts. Let's see if this is useful.

This is a "product package" for:

• Glance blueprint "Ability to authorize interaction with entity properties"
• Blueprint full specification: "Glance-property-protections"

Press Release

Protections Now Available for Image Properties

The OpenStack Image Registry and Delivery Service (Glance) proudly announces the availability of property protections in the Havana release. Many providers use image properties to provide information to a billing service or to a Nova extension, and it's important that image owners not modify the values of these properties. Or it may be the case that a provider wants to encourage image sharing and image discovery by providing some standard image properties that image owners can use. Or a provider may wish to store hidden system information on an image.

This feature enables a provider to configure Create-Read-Update-Delete permissions on image properties on a per-name basis using a simple pythonic configuration file. The feature is aimed at cloud providers in their capacity as glance admin; image owners do not have the ability to put protections on owner-created properties.

This feature is effective in both version 1.x and version 2.x of the Images API.

Property Protections FAQ

What are "property protections"?

There are two types of properties in Glance:

• properties (or "core" properties) ... these are the ones defined in the image schema
• additional properties ... these are arbitrary key/value pairs that can be put on an image

Some of the "core" properties are already protected in code, e.g., an image owner can't modify the checksum, created_at, or updated_at properties. These are important for correct functioning of Glance and their protections will not change.

Property protections allow you to limit what specific categories of users can do CRUD on a particular property. Properties that don't have protections defined for them will act as they do now, i.e., admin CRUD on core properties, owner CRUD on additional properties.

What roles are available for configuring property protections?

Whatever roles you have defined in policy.json in your glance installation.

How does setting protections on a property affect its display?

It doesn't. The properties are displayed in the image response according to the image schema. If the user making the image detail request does not have read permission on a property, that property will be "hidden", i.e., it will not appear in the response.

How do you configure property protections?

Python-style config file. The file will be scanned from top to bottom, first match wins. The file allows use of a regex to indicate the property name.

How will my users know what properties are protected?

That's up to you. The communication must be done independently of Glance. We suggest that you use an informal namespacing for properties you want to protect, e.g., use the prefix com_provider_ before all the additional properties you want to put on images. You can even use the configuration file to enforce restrictions so that image owners can only create properties in an informal namespace, e.g., only allow non-admin create permission on properties whose names begin with owner_specified_. The feature is very flexible, how you want to do this is entirely up to you.

Why not include protected properties in the image JSON schema or something?

One of the use cases that came up during discussion at the Havana summit was for "hidden" properties that a provider could put on images, i.e., not only could a user not read the value, the user shouldn't know that the property exists. So these would have to be excluded from the schema, which is doable, but could be confusing, since different users will see different JSON schemas depending on their permissions. Additionally, at this point we don't know exactly how cloud providers will be using this feature, so it's best to leave configuration and communication up to the provider for Havana.