Difference between revisions of "Glance-property-protections-product"
(Created page with "== Press Release == === Protections Now Available for Image Properties === The OpenStack Image Registry and Delivery Service (Glance) proudly announces the availability of p...") |
m |
||
| Line 7: | Line 7: | ||
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 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 <tt>com_provider_</tt> 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 <tt>owner_specified_</tt>. The feature is very flexible, how you want to do this is entirely up to you. | ||
Revision as of 14:39, 25 July 2013
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.
