Achieving Zen-like Bliss with Glance Brian Rosmaita, irc: rosmaita - - PowerPoint PPT Presentation

Achieving Zen-like Bliss with Glance

Brian Rosmaita, irc: rosmaita Erno Kuvaja, irc: jokke_

November 2017

Brian Rosmaita

Distinguished Member of the Technical Staff Verizon Wireless

Erno Kuvaja

Senior Software Engineer

The OpenStack Image Service

The OpenStack Image Service (codenamed “Glance”) is developed and maintained by the Glance project. Glance allows you to to store, browse, share, distribute, and manage bootable disk images. The glance software provides the Image Service APIs.

• Version 2 is under active development
• Version 1 is DEPRECATED and scheduled to be

removed in the Queens release developer.openstack.org/api-ref/image

More Glance at the Summit

• Operators’ Feedback Session

○ Tuesday, 4:10-4:50pm ○ Level 4 - C4.11

• Glance Project Update

○ Wednesday, 11:25-11:45am ○ Level 3 Convention Center - C3.2

• Glance Image Import is here ... now it's time to

start using it! ○ Wednesday, 4:30-5:10pm ○ Level 3 Convention Center - Cockle Bay Room 2

1.

How do I discover images ?

2.

How do I share images effectively with my organization?

3.

How can I make better use of my image metadata using property protections?

4.

How do I ensure the authenticity of image data using digital signature?

5.

What are image locations? Are they appropriate for my cloud?

6.

What is the new image import workflow, and what does it do for me?

Questions

How Do I Discover Images?

November 2017

➡ The Glance image-list call ➡ GET /v2/images

• Things to know about the default image-list response
• Operator configuration options:
• limit_param_default = 25
• api_limit_max = 1000
• End-user supplied parameters:
• limit
• The default response does not contain all images

available to the end user

• This is an anti-spam feature

How do I discover images?

➡ The Glance image-list call ➡ GET /v2/images

• Things to know about the default image-list response
• Default content (no query parameters other than limit or sorting)
• All public images (regardless of owner)
• All private images owned by the end user
• All community images owned by the end user
• All shared images that the end user owns
• All shared images that the end user has accepted
• What’s missing
• Community images provided by other owners
• Shared images that haven’t been accepted

How do I discover images?

➡ The Glance image-list call ➡ GET /v2/images

• Use the ‘visibility’ filter to discover the “missing” images
• GET /v2/images?visibility=community
• All community images (including the ones you own)
• GET /v2/images?visibility=community&owner=be2565a54dad45
• All community images owned by that particular producer
• Use your owner identifier to see only your community images

How do I discover images?

➡ The Glance image-list call ➡ GET /v2/images

• Use the ‘visibility’ filter to discover the “missing” images
• GET /v2/images?visibility=shared
• All shared images that the end user owns
• All shared images that the end user has accepted
• (so, basically, only the shared images that show up in the default list)
• GET /v2/images?visibility=shared&member_status=all
• All shared images that the end user may use
• Can also use ‘accepted’, ‘pending’, or ‘rejected’ for the member status

filter

How do I discover images?

➡ The Glance image-list call ➡ GET /v2/images

• You can filter on any image property
• Image properties (“metadata”) tend to be subject to local practices
• Glance “common image properties” are an attempt to provide some common

properties with standardized values across OpenStack clouds

• Limitations
• The API pretty much only allows conjunctions in query strings, and no

negations

• You can form disjunctions (but only on some fields) using the ‘in’ operator

(introduced in Mitaka)

• The ‘name’ filter specifies an exact match
• To allow users to do complex searches, we suggest you deploy Searchlight (the

OpenStack front end to ElasticSearch)

How do I discover images?

➡ The Glance image-list call ➡ GET /v2/images

• Size comparison filters
• size_min - only return images larger than the specified size (in bytes)
• size_max - only return images smaller than the specified size (in bytes)
• Time comparison filters
• Can be applied to created_at and updated_at
• Introduced in Mitaka

How do I discover images?

How Do I Share Images Effectively With My Organization?

November 2017

➡ Well, it depends on who you are and what you want to accomplish! ➡ We’ll consider “sharing” to mean “make an image available to someone other than the

image owner”

➡ In Glance, who has access to an image is tied to the image’s ‘visibility’ property

• public
• community
• shared
• private

➡ You change an image’s visibility by using the image-update (PATCH) call

• Can also specify visibility at the time of image creation
• Default is ‘shared’
• The ability to share is governed by policies

How do I share images effectively?

➡ Public images

• The image is available to all users
• Only the owner (or an admin) can update or delete the image
• Policy target: “publicize_image”: “role:admin”
• These are a cloud’s “base images”
• The basic idea of a public image is that there is some kind of support relationship

between the operator and end users

• Because most clouds treat them this way, there’s an expectation on the part
• f end users
• The ability to publicize an image can be extended to whoever you like, but it’s

best to keep this expectation in mind

How do I share images effectively?

➡ Community images

• The image is available to all users
• Only the owner (or an admin) can update or delete the image
• Policy target: “communitize_image”: “”
• These are images made available to the entire community of users in a cloud
• Original use case was open-source projects who wanted to make make an image

available to all users, and were willing to maintain the image and support it themselves

• Useful if you just want an image to be available, but you have no need to know who

exactly has access to it

How do I share images effectively?

➡ Shared images

• The image is available only to specific users who must be made “members” of the

image

• Only the owner (or an admin) can update or delete the image
• Only the owner (or admin) can add or delete image members
• Only a member (or admin) can modify that member’s member_status
• Policy targets:
• "add_member": ""
• "delete_member": ""
• "get_member": ""
• "get_members": ""
• "modify_member": ""

How do I share images effectively?

➡ Shared images

• The image must have ‘shared’ visibility in order for members to be added (since

Ocata)

• Simply having ‘shared’ visibility does not imply that anyone other than the owner

has access to the image

• Must also have a non-empty member list
• Shared images are useful if you only want specific other projects* to have access to

the image

• The member_status of an image member does not affect access to the image
• It affects whether the image will appear in a member’s default image list
• The image is available to a member as soon as that member is added to the

image

How do I share images effectively?

How can I make better use of my image metadata using property protections?

November 2017

➡ Property protections were introduced in Havana ➡ Allow an operator to specify CRUD on custom image properties (“image metadata”) ➡ Called “property protections” instead of “protected properties” because they’re not a

particular kind of image property

• They provide an authorization layer around all the custom image properties

➡ Can be configured to use roles or policy rules to describe the permissions ➡ Left to the operator to document how the protections are set in a particular cloud

• (This is mentioned several places in the Image Service API reference)

How can I make better use of my image metadata using property protections?

➡ Configuring

• Related options
• allow_additional_image_properties (default is True)
• When False, only properties specified in the image schema are allowed
• image_property_quota (default is 128)
• Primary options
• property_protection_file (default is empty string)
• Activate property protections by specifying a file
• property_protection_rule_format (default is ‘roles’)
• Tells Glance what to expect in the property_protection_file
• ‘roles’ or ‘policies’

How can I make better use of my image metadata using property protections?

➡ The property_protection_file

• If you specify one, it covers all your custom image properties
• The feature is very conservative
• If the file can’t be found, the API service won’t start
• If there’s a problem with the file content, the API service won’t start
• If a property is not mentioned in the file, the permissions are deny-all for that

property

• You probably want a catch-all clause at the bottom of the file

How can I make better use of my image metadata using property protections?

➡ The property_protection_file

• Written in roughly ini-file format
• Each protection clause appears in square brackets [ ]
• Each clause is a regular expression
• Each clause must be followed by four key-value pairs
• Each key is one of { create, read, update, delete }
• Followed by =
• Followed by either a list of roles or a rule (depending on how

property_protection_rule_format is set)

• The file is read top-down, first match wins
• The feature is very conservative
• If one of the keys is missing, the API service will refuse to start

How can I make better use of my image metadata using property protections?

➡ Hints

• The protection descriptors are regular expressions -- very powerful, but also very

easy to misconfigure

• [very_protected]
• Will match ‘very_protected’, ‘not_very_protected’, ‘very_protected_not’
• Probably mean [^very_protected$]
• [^com\.mycloud.*]
• Protects all properties beginning ‘com.mycloud’
• Important to have tests to make sure the protections (a) do what you want, and (b)

don’t do more than you want

How can I make better use of my image metadata using property protections?

➡ Hints

• If you use rules to define the protections, you may want to define specific policy

rules that are different from your other glance policy rules

• How do property protections affect end users?
• image-create, image-update calls may fail:
• 403 Forbidden
• Attribute 'my.property' is reserved.
• This can be annoying, so best to pick a convention for your cloud concerning

what’s allowed and publish it

• Detailed information in “Property Protections” in the Glance Administration Guide

How can I make better use of my image metadata using property protections?

How do I ensure the authenticity of image data using a digital signature?

November 2017

➡ Glance has had this capability since Liberty ➡ It was strengthened in Newton to eliminate dependency on MD5 ➡ Requires a bit of infrastructure

• See the “Trusted Images” section of the OpenStack Security Guide
• See the “Image Signature Verification” section of the Glance User Guide
• Requires Barbican
• Barbican stores the public key certificate
• Requires the operator to configure Nova to do image signature verification
• verify_glance_signatures = True in the nova.conf file

How do I ensure the authenticity of image data?

➡ Requires offline work by the end user

• End user must upload the certificate to Barbican independently
• End user must generate the signature
• End user must supply a certificate reference, a signature algorithm identifier, a hash

method identifier, and the signature

• Signature is limited to 255 chars
• End user must specify the above as image properties at the time of image creation
• img_signature
• Img_signature_hash_method
• Img_signature_key_type
• img_signature_certificate_uuid

How do I ensure the authenticity of image data?

➡ What Glance does

• When the image data is uploaded, Glance retrieves the certificate from Barbican and

validates the data based on what Glance has computed during the upload vs. the signature stored as an image property

• If the validation fails, the upload fails and the image is deleted

How do I ensure the authenticity of image data?

What are image locations? Are they appropriate for my cloud?

November 2017

➡ Image locations are part of the Images API that exposes the values which Glance uses to

track the actual data associated with images.

➡ Per default the API exposing the locations is disabled by configuration and allowed in

policies.

➡ Every Glance deployment uses image locations but none of them should expose it to their

end users

• There has been various Security bugs and advisories filed against the exposure of

locations

• Breaks the abstraction layer Glance provides about the backends
• Allows the users to do potentially stupid/dangerous things

What are image locations? Are they appropriate for my cloud?

➡ There are legit use cases to expose the locations API:

• Glance and Nova sharing Ceph store at which point Nova needs to be able to talk to

glance locations to do snapshots etc.

• Admin migrating images between storage backend

So why do we have this feature still?

How does one configure locations API properly?

➡ Effectively only way to do this right is to have fenced out nodes for

the needed use cases

• Private set of glance-api nodes that are accessible by Nova

but not by the public

• Dedicated admin node(s) with the same

What is the new image import workflow, and what does it do for me?

November 2017

➡ We’ll only touch on this briefly today ➡ There’s a full session devoted to the new interoperable image import process later this

week

• Wednesday, 4:30pm-5:10pm
• Sydney Convention and Exhibition Centre
• Level 3 Convention Center
• Cockle Bay Room 2

What is the new image import workflow, and what does it do for me?

@OpenStack

Q&A

Thank you!

• penstack
• penstack

OpenStackFoundation