Jump to: navigation, search


We're going to take a Minimal Viable Product approach here and see where that gets us.

What are "property protections"?

There are currently 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

Under this proposal, any of the above could become "protected properties" by defining protections for them. When you put protections on a property, it limits what specific categories of users can do CRUD on that 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.

How do you specify property protections?

The simplest thing is to use a config file. It could look something like this:

create: <role-list>
read: <role-list>
update: <role-list>
delete: <role-list>

where role list is based on policy.json

<role-name>: <crud-list>
<role-name>: <crud-list>
<role-name>: <crud-list>

How do you display properties that are protected?

They'd look exactly as they do now in the Image response except that you might not see them at all depending on your permissions.

Namespacing and property protections

There will be no explicit namespacing, informal "namespacing" would continue as it does now, e.g., "system" properties would be prefaced with something like "org.openstack__1__" or "com.cloudprovider__1__". The downside is that since protections are name-based, if an image owner has an existing property name that matches a protected name, the image owner may not be able to edit his own property. On the other hand, the whole point of the javaesque informal namespacing in the first place was to prevent this kind of conflict, so we (well, me, anyway) are not concerned.

Open Questions

  • How should the names of properties with protections on them be communicated to a user?
    • I think this should be done independently of glance, leave it up to the cloud provider to communicate this via documentation.
  • Should the protections act like policies, i.e., could be independent for each node, or should we enforce consistency across all nodes?
    • I'm personally all for consistency here.