Open Stack

On Mon, May 13, 2013 at 9:47 AM, Scott Moser <smoser at ubuntu.com> wrote:

> 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).
>
>
Config drive for baremetal seems possible for some (but not all) hardware.
Clearly, we'll need to support multiple deployment models :)

However, detaching from the management network seems like less than great
security to me. The moment that the user requests any management of their
instance be performed, you'll have to reconnect it to the management
network *before* you can power it down (or do what ever else you need).
There is still a clear (though perhaps shorter) window where the tenant has
access to the management network.

Also, the management network is the only vector for the cloud operator to
monitor the health of a bare metal instance (eg., poll power state and hw
sensors over IPMI). Not having that visibility seems, well, like a bad idea
to me.

-Devananda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130513/e9619e01/attachment.html>