<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 13, 2013 at 9:47 AM, Scott Moser <span dir="ltr"><<a href="mailto:smoser@ubuntu.com" target="_blank">smoser@ubuntu.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri, 10 May 2013, Clint Byrum wrote:<br>
<br>
> Excerpts from Scott Moser's message of 2013-05-10 12:50:24 -0700:<br>
> > On Wed, 8 May 2013, Michael Still wrote:<br>
> ><br>
</div><div class="im">> > The benefits of this path are:<br>
> > a.) openstack has a 'contract' of sorts with images, rather than mucking<br>
> > around inside them.<br>
> > b.) The OS can handle bootloading itself (as opposed to having openstack<br>
> > have to poke around inside looking for something name 'kernel' or<br>
> > 'initrmafs' or other such silly things. And also figure out what<br>
> > kernel cmdline parameters it should hve.<br>
> > c.) This can work for windows or bsd or whatever. The images are made for<br>
> > openstack.<br>
> ><br>
><br>
> If I understand it right, the problem that file injection and config<br>
> drive are trying to solve is that the "ec2 metadata" service is not<br>
> considered safe enough for some environments because:<br>
><br>
> a) MITM attacks from other tenants are in theory possible if they can<br>
> spoof all of the right things.<br>
> b) This requires that instances be able to reach some Nova API node that<br>
> then has access to the rest of the nova infrastructure.<br>
<br>
</div>Well, the original desire for "config-drive" versus "openstack http based<br>
metadata service" really came more over a dis-interest in relying on dhcp.<br>
In my opinion, that never actually was well described or justified, but<br>
lets not go into that now. For many people config-drive is superior to<br>
a web service. If nothing else, it allows you to insert networking<br>
information explicitly, and to tell the node where the metadata service is<br>
(if its not available on <a href="https://169.254.169.254" target="_blank">https://169.254.169.254</a> .. yeah, you could<br>
probably use dns/dns-sec for that).<br>
<div class="im"><br>
> Problem "b" is pretty simple to solve in Nova by having a more clear<br>
> hand-off between the sensitive bits of nova and the metadata service.<br>
><br>
> Making the partition solution above more useful than HTTP metadata<br>
> services for baremetal would also mean having a secure way to send<br>
> the image to the node to boot, or problem "a" will not be solved. With<br>
> metadata, we have a separation of concerns here by accepting that PXE<br>
> and tftp are not secure and will need to be locked down, but the metadata<br>
> could be secure by simply using HTTPS.<br>
><br>
> I'm not sure why this would be superior to just implementing HTTPS<br>
> metadata services. Images can have PKI built in for authentication<br>
> of the metadata host. This allows full control of the trust model by<br>
> image authors.<br>
><br>
> To me, HTTPS metadata is as simple as partitions and filesystems, and<br>
> more flexible.<br>
<br>
</div>I largely agree here, but we have config-drive in nova. I think it makes<br>
sense to have an analog in bare metal provisioning. In bare metal, it<br>
would actually allow the nodes to never have access to the management<br>
network while in "user" possession (ie, detach pxe/management network<br>
after system installed).<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div style>Config drive for baremetal seems possible for some (but not all) hardware. Clearly, we'll need to support multiple deployment models :)</div>
<div><br></div><div style>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.<br>
</div><div style><br></div><div style>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.</div>
<div style><br></div><div style>-Devananda</div></div></div></div>