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:
[mypropertyname] create: <role-list> read: <role-list> update: <role-list> delete: <role-list>
where role list is based on policy.json
[mypropertyname] <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.