Open Stack

Excerpts from Scott Moser's message of 2013-05-10 12:50:24 -0700:
> On Wed, 8 May 2013, Michael Still wrote:
> 
> > I would not say that file injection is a requirement at the moment for
> > a nova hypervisor driver. In fact, there's been discussion for a
> > couple of releases about turning it off for everyone. I'd like to see
> > it deprecated in Havana for removal in Incarceration [1] if at all
> > possible. Some more discussion of if that's possible would be nice.
> >
> > However, I do think you need to support configdrive if you're not
> > doing file injection. I say this because some deployments cannot use
> > metadata server (for example, network policy may not allow instances
> > to talk to infrastructure nodes). So, I think having that would be
> > good.
> 
> I spoke with Robert at the summit, and have thought about "config-drive"
> and bare-metal provisioning a bit since.
> 
> I really prefer openstack to generally offer a "platform" for images to
> target.  Ie, the image is made so that it works well with openstack (it
> reads data from config-drive or ec2-metadata) rather than openstack
> making images work (file injection).
> 

+1 image content never being introspected by OpenStack. They are bytes
to be fed to a computer... be it kvm, xen, or a baremetal node.

> In that direction, for bare-metal, what I thought makes most sense is the
> following:
>  * images from openstack's perspective are just a bunch of blocks (in raw
>    format or qcow2 format) as opposed to a tarball of a root filesystem.
>  * installation of that image, pretty much looks like this:
>    convert-image-to-stdout input.img | dd if=- of=/dev/sda
>  * The image, then is in charge of handling the partition table or
>    otherwise making the OS boot.  Ie, your image is likely to be
>    partitioned and have grub installed in the master boot record or GPT
>    partitioned with EFI. The key thing here is that ironic pretty much
>    doesn't care.
>  * The "communication" mechanism from an image to ironic is via a
>    partition that is identified. For example we might choose to require
>    that there be a partition with a vfat filesystem.  In GPT, I think we
>    can actually identify it better by expecting for there to be a label
>    'config-v2'.  In DOS partition it would be 'Id' of '99' (or something).
> 
>  * After 'dd' of the image, ironic would then re-read the partition
>    tables, and search for this partition.
>    If it finds it, it can insert data like the data that goes into
>    config-drive-v2 (or some other format)
>  * The OS, when it boots reads this new "datasource" and operates the same
>    way it does with ec2 metadata or openstack configdrive.
> 
> The benefits of this path are:
>  a.) openstack has a 'contract' of sorts with images, rather than mucking
>      around inside them.
>  b.) The OS can handle bootloading itself (as opposed to having openstack
>      have to poke around inside looking for something name 'kernel' or
>      'initrmafs' or other such silly things. And also figure out what
>      kernel cmdline parameters it should hve.
>  c.) This can work for windows or bsd or whatever. The images are made for
>      openstack.
>

If I understand it right, the problem that file injection and config
drive are trying to solve is that the "ec2 metadata" service is not
considered safe enough for some environments because:

a) MITM attacks from other tenants are in theory possible if they can
spoof all of the right things.
b) This requires that instances be able to reach some Nova API node that
then has access to the rest of the nova infrastructure.

Problem "b" is pretty simple to solve in Nova by having a more clear
hand-off between the sensitive bits of nova and the metadata service.

Making the partition solution above more useful than HTTP metadata
services for baremetal would also mean having a secure way to send
the image to the node to boot, or problem "a" will not be solved. With
metadata, we have a separation of concerns here by accepting that PXE
and tftp are not secure and will need to be locked down, but the metadata
could be secure by simply using HTTPS.

I'm not sure why this would be superior to just implementing HTTPS
metadata services. Images can have PKI built in for authentication
of the metadata host. This allows full control of the trust model by
image authors.

To me, HTTPS metadata is as simple as partitions and filesystems, and
more flexible.