Open Stack

On Fri, 10 May 2013, Clint Byrum wrote:

> Excerpts from Scott Moser's message of 2013-05-10 12:50:24 -0700:
> > On Wed, 8 May 2013, Michael Still wrote:
> >
> > 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.

Well, the original desire for "config-drive" versus "openstack http based
metadata service" really came more over a dis-interest in relying on dhcp.
In my opinion, that never actually was well described or justified, but
lets not go into that now. For many people config-drive is superior to
a web service.  If nothing else, it allows you to insert networking
information explicitly, and to tell the node where the metadata service is
(if its not available on https://169.254.169.254 .. yeah, you could
probably use dns/dns-sec for that).

> 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.

I largely agree here, but we have config-drive in nova.  I think it makes
sense to have an analog in bare metal provisioning.  In bare metal, it
would actually allow the nodes to never have access to the management
network while in "user" possession (ie, detach pxe/management network
after system installed).