[glance][nova][cinder] Openstack Glance image signature and validation for upload and boot controls?

S Andronic sandronic888 at gmail.com
Sat Oct 23 15:31:01 UTC 2021


Hi Brian,

Thank you very much for your reply and the references, it has been most
helpful.

Kind regards
S. Andronic

On Fri, 22 Oct 2021, 00:52 Brian Rosmaita, <rosmaita.fossdev at gmail.com>
wrote:

> On 10/20/21 8:24 AM, S Andronic wrote:
> > Hi,
> >
> > I have a question in regards to Openstack Glance and if I got it right
> > this can be a place to ask, if I am wrong please kindly point me in the
> >   right direction.
> >
> >   When you enable Image Signing and Certificate Validation in nova.conf:
> >   [glance]
> >   verify_glance_signatures = True
> >   enable_certificate_validation = True
>
> Note: Since Rocky, if you have enable_certificate_validation = True but
> have default_trusted_certificate_ids at its default value of empty list,
> then a user must supply a list of trusted_image_certificates in the
> create-server request, or the request will fail.
> >
> >   Will this stop users from uploading unsigned images
>
> No, glance doesn't have a setting that requires uploaded images to be
> signed.  However:
> - If the image record contains *all* the appropriate image signature
> properties, the PUT /v2/images/{image_id}/file call will fail if the
> data can't be validated.
> - You could write an image import plugin that would disallow import of
> image data for which the image record doesn't have the image signature
> properties set.
>
> > or using unsigned
> >    images to spin up instances?
>
> Yes, if verify_glance_signatures is True, nova won't boot unsigned images:
>
> https://docs.openstack.org/nova/latest/configuration/config.html#glance.verify_glance_signatures
>
> >   Intuitively I feel that it will enforce checks only if the signature
> >   property exists, but what if it doesn't?
>
> See above.
>
> >   Does it control in any way unsigned images?
>
> Yes, if verify_glance_signatures is True, unsigned images can't be used
> to boot an instance.
>
> >   Does it stop users from uploading or using anything unsigned?
>
> No, glance doesn't require it.
>
> >   Would an image without the signing properties just be rejected?
>
> It depends on what service you are talking about:
>
> Glance: no, glance won't reject an unsigned image.
>
> Nova: yes, if verify_glance_signatures is set.
>
> Cinder: it depends ... if verify_glance_signatures is enabled:
> - if you create a volume from an image AND the image has *any* of the
> image signature properties set, cinder will try to validate the image
> data and the volume will go to error if validation fails.  If the
> validation succeeds, you get signature_verified: true in the
> volume-image-metadata.
> - if you create a volume from an image AND the image has NONE of the
> image signature properties, the volume creation will succeed (assuming
> nothing else goes wrong) and you get signature_verified: false in the
> volume-image-metadata.
>
> But ... Nova won't do certificate validation for a boot-from-volume
> request (as described in [0]).  But I'm not clear on what happens if
> verify_glance_signatures is true and enable_certificate_validation is
> false.  I believe that nova will boot the volume on the theory that
> cinder has already handled the signature validation part (which it has,
> if the option is enabled and at least one image signature property is
> set on the image), and it's the certificate validation part that isn't
> being handled?  Hopefully someone else will explain this.
>
> [0]
>
> https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/nova-validate-certificates.html
>
> >   If this feature doesn't stop the use of unsigned images as a security
> >   control what is the logic behind it then?
>
> I guess you can look at the spec to see what threat models the feature
> was proposed to address:
>
> https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/image-verification.html
>
> >   Is this meant not to stop users from using unsigned images but such
> >   that people who do use signed images have verification for their code?
>
> This is a good question, and the asymmetry between how nova and cinder
> treat requests to create a resource from an unsigned image when
> verify_glance_images is enabled makes this difficult to answer (at least
> for me).
>
> >   So if the goal is to stop people from using random images and image
> >   signing and validation is not the answer what would be?
>
> It really depends on what your cloud users want/need, and what you mean
> by a "random image".  For example, you could only allow public images
> provided by you the operator to be used to boot servers by blocking
> image uploads and server snapshots, or allowing snapshots but not
> allowing image sharing (which could get you "random" images, but they'd
> be restricted to a single project, which would probably be OK).  Like I
> said, it depends on your goals and what your users will put up with (I
> think users would absolutely hate not being able to create server
> snapshots, but there are probably some users for whom that wouldn't be a
> problem).
>
> While we're talking about server snapshots, however, note that with
> verify_glance_images enabled in nova, you can boot a server from a
> signed image and then use the server createImage action to create an
> image in Glance.  This image won't have the image signature properties
> on it, however, and hence won't be bootable.  Your users will have to
> download the image so they can generate a signature for it and then set
> all the image signature metadata on the image before it nova will boot
> it.  (I'm pretty sure this is true.)
>
> You may want to send another email with '[ops]' in the subject line to
> ask other operators who use this feature what their configuration and
> experiences are like.
>
> >
> >   Kind Regards,
> >   S. Andronic
>
> Good luck!
> brian
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20211023/a8f8f895/attachment.htm>


More information about the openstack-discuss mailing list