Obsolete:Glance-protected-properties
This document is outdated. It is superceded by https://wiki.openstack.org/wiki/Glance-property-protections
This is an attempt to structure some of the current thinking from the etherpad: https://etherpad.openstack.org/public-glance-protected-props It's a work in progess, feel free to comment/edit.
In order to implement Glance protected properties, we'll need to do the following:
- Figure out what "protected properties" are
- Display protected properties
- Protect protected properties
- Configure protected properties
- Do CRUD on protected properties
- Store protected properties
- Nova consumption of protected properties
Contents
Defining 'protected properties'
Stuart and Iccha have done good work on this in the etherpad. Right now, Glance has two sets of properties that can be put on an image:
- core properties (e.g., name, id, min_ram)
- user properties (arbitrary end-user-specifiable key/value pairs)
We're proposing a new category
- protected properties
These would be arbitrary key/value pairs, but would be specified by the cloud provider (i.e., Glance admin). The "protection" for these properties is that the Glance admin could configure access controls for end-users, e.g., some properties could be read only, some could be hidden (only readable/writable by an admin), some could be end-user-modifiable. So these would be like user properties in that they would be unknown when we shipped Glance, and they would be like core properties in that they would have the same names (and protections) on all images.
We think it makes sense to have this be a separate category of property rather than shoehorn them into either core or user properties. Current consumers of images (e.g., Nova) rely upon the core properties, so we don't want to mess with those. As far as user properties go, they are definitely useful currently, we're not sure whether there's a compelling use-case for allowing an image owner to protect these in the way we want to allow a cloud provider to protect the protected properties, and we don't want to delay implementation of protected properties trying to figure out how to extend protection to user properties. (Once protected properties are implemented, this question could be revisited.) So the three categories of properties are conceptually separate; at this point, it looks like it makes sense that they'd be implemented differently. In any case, that's what we're thinking right now.
Display protected properties
The image response could look something like this:
"image" : {
"core1" : "value",
"core2" : "value"
},
"metadata" : {
"key1" : "value",
"key2" : "value"
},
"system" : {
"pp1" : "only-a-glance-admin-can-see-me",
"pp2" : "i-am-read-only-for-non-admins"
}
}
The core* are core properties, the metadata field contains the user properties, the protected properties are in the system field. We think it makes sense to keep the protected properties separate from the others, it reflects their purpose and also will be less confusing for end-users.
Protect Protected Properties
(Once we've figured out how to configure protected properties and what the operations on them will be, the actual protection will have to be implemented.)
Configure Protected Properties
We need to figure out:
- how to define what the protected properties are for a particular Glance installation
- current thinking is that this would be done at deploy time; since these are a kind of "system" property, a cloud provider should know what they are in advance
- could do this in a JSON schema, though this would *not* be the same schema that an end-user would see in the image-schema response
- Glance v2 is using JSON schema v3 right now, so if we went the JSON schema route, we'd have to switch to JSON schema v4,[1] which allows you to extend the schema keywords (so we could add something like a "protections" keyword that would allow you to define the protections on the property).
- how to display this information (i.e., not the key/values themselves, but what the keys are and what the protections on them are)
- how to incorporate this information into the v2 image-schema response (e.g., end-user consumers of the image-schema should know that property pp2 in the example above exists, but should not know about property pp1; Nova, however, should know about both pp1 and pp2)
CRUD on protected properties
We need to figure out what the API calls will look like that set values for these properties on a particular image.
Storing protected properties
They'll go in the database somewhere, but in their own table or with the user properties? We don't want to slow down the image detail response, but we also need to know how the protections apply to the user making the image detail request.
Nova consumption of protected properties
(This may be beyond the scope of this blueprint, but it's worth thinking about. Since these are a type of system property, it would make sense that we'd want Nova to propagate some of them to an instance when an instance is booted. So Nova will have to be able to read protected properties. Should Nova also have to respect the protections, so that, e.g., a hidden image property becomes a hidden server property?)
