openstack team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

On Tue, 10 Apr 2012, Justin Santa Barbara wrote:

> Signing would definitely be a great v2 feature.  For v1, we just need some
> way to know that an image is provided by the cloud provider, and some idea
> of what that image "is".
>
> I believe every cloud is stuck respinning their own images, because we
> haven't been able to agree a "golden image" standard.  So signing etc by
> the distros is pointless until we get that figured out.

Really?
Because the ubuntu cloud images work in EC2 or Openstack or Eucalyptus or
<insert-other-lesser-known-cloud-here>.  No modification is necessary.

> I trust the cloud providers today - I have no choice but to do so.  I think
> you're trying to solve a much harder problem - how do I cope in a world
> where I trust Canonical but not my cloud?  Once we have hardware trust of
> clouds, then we'll have to up our game substantially on every front here.

No.  You trust the cloud provider, thats one thing.
The cloud provider is not necessarily the image provider.  I trust
Canonical, I trust Amazon.  I do not trust image id 938181839409 who
produced 'hackerz/Ubuntu-11.10-great-package-list-for-smoser'.

3 scenarios:
 a.) canonical publishes an image to a public cloud (like they do to EC2).
     I trust Amazon, I trust canonical, I know that canonical publishes
     images under id X.

 b.) public cloud startupcloud.com publishes Ubuntu images.
    If i'm running images on startupcloud.com, I obviously have to trust
    them.  Canonical couldn't care less about them, so startupcloud.com,
    uses the data at https://cloud-images.ubuntu.com/query2/ to mirror
    ubuntu images.  They use the naming convention suggested by the Ubuntu
    to identify those images.  Because of  my trust in startupcloud.com
    I can reasonably assume that these images are what they expect.
    If glance provides me the MD5SUM of the image that i'm going to run,
    I can actually, then verify that against the data in /query2 and have
    even higher confidence that this is what I think it is.

    Here, startupcloud.com could have glance lying to me, thats true, but
    I'm already stuck trusting them.  So this is just a more specific
    bit of information available.

 c.) joeuser starts using startupcloud.com and likes them, but thinks they
     can improve on their Ubuntu images, so he starts making public images
     named "joeuser/ubuntu-images/<ubuntu-naming-convention>"

    I try one of these, and start to develop a trust in joeuser as a
    provider.  Now, I can use his public gpg keys and trust him.

> On Tue, Apr 10, 2012 at 8:04 AM, Scott Moser <smoser@xxxxxxxxxx> wrote:
>
> > The data you're after might be useful to you, and might scratch an itch.
> >
> I will not discount that, but I would much prefer a bit of metadata
> > associated with an image that was signed by an entity I trusted that
> > identified the image as good.
> >
>
> I have to trust my cloud provider.  A single protected flag in metadata
> saying "official cloud image" is no less secure than anything more
> complicated at the moment (sadly)

Agreed.

> OS distro, version_major, version_minor are even less important where you
>
> don't care (or know) that your OS came from Canonical or RedHat, what you
> > were really interested in is running "WhizBang! Fooberator" version 2.0.
> >
>
> Unless the distros stop changing config directory locations, or agree a
> common init.d approach, then this simply isn't true.

Well, in the case that you care about that, yes.  In that case, you need
to know things like that.  But largely that can be determined from inside
the instance, and is usually handled by tools accounting for such
differences.

> Maybe you're talking about running pre-built appliances?  I'm talking about
> not treating the machines as infallible black boxes (I think mine is the
> more common use case, but irrespective, mine is definitely a valid use case)

The Ubuntu images are pre-built appliances.  All images are in some sense.
They come from a vendor, which you hopefully have some level of trust in.
You interact with the appliance via some interface.  Some might be a web
interface, some might be cloud-init, some might be puppet or chef.

Its all just use of an interface.  The OS is just a means to an end.

Your case is valid, yes. but if you have public images, then you cannot
trust the content of the image with out trusting the source.  So user
provided tags (or even tags pulled by libguestfs) are useless.

> It's very important to me as a consumer of images.  How are you coding
> image selection for launching instances on the public OpenStack clouds?
>  I'm interested in any alternative.

I guess largely my issue is that your wanting openstack to define a
namespace for users of it to adhere to.  You're suggesting that in that
namespace shoudl be things like "os_version", which I do believe is
important, but not all important.

Having recently played with iscsi, I read the naming convention bits at
http://tools.ietf.org/html/rfc3721#section-1.1 .  I feel that it would be
better to specify a general naming convention, and leave it at that.

If you see something that is named
  img.2004-05.com.ubuntu:maas:ubuntu-precise-daily-i386-server-20120409.1

Then you can expect that the owner of the com.ubuntu domain built that
name, and hopefully can somehow get information about that name means from
them.  (And, because they've signed that name and the checksum, you can
verify that either glance has been configured to lie to you by its vendor,
or it actually is what you think).

I really hope to get lots of this accomplished in the near future.  We
hope to have a public glance server serving content from ubuntu.com, that
you (or other vendors) can just reference in their configuration, and have
ubuntu images just show up there.
>