<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 17, 2014 at 12:35 PM, Alan Kavanagh <span dir="ltr"><<a href="mailto:alan.kavanagh@ericsson.com" target="_blank">alan.kavanagh@ericsson.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Rob<br>
<br>
Then apart from the disk eraser and reinstalling the blade from scratch everytime it is returned from lease, and ensure network isolation, what are the other many concerns you are worried about for sharing the bare metal then? Would really like to know what the other "major issues are" that you see?<br>
<br>
/Aaln<br>
<div class="im"><br></div></blockquote><div><br></div>Alan,<div><br></div><div>Disk erasure is, in my opinion, more suitable to policy compliance, for instance wiping HIPAA / protected information from a machine before returning it to the pool of available machines within a trusted organization. It's not just about security. We discussed it briefly at the HKG summit, and it fits within the long-tail of this blueprint:</div>
<div><br></div><div><a href="https://blueprints.launchpad.net/ironic/+spec/utility-ramdisk">https://blueprints.launchpad.net/ironic/+spec/utility-ramdisk</a><br></div><div><br></div><div>To answer your other question, the security implications of putting untrusted tenants on bare metal today are numerous. The really big attack vector which, AFAIK, no one has completely solved is firmware. Even though we can use UEFI (in hardware which supports it) to validate the main firmware and the OS's chain of trust, there are still many micro controllers, PCI devices, storage controllers, etc, whose firmware can't be validated out-of-band and thus can not be trusted. The risk is that a prior tenant maliciously flashed a new firmware which will lie about its status and remain a persistent infection even if you attempt to re-flash said device. There are other issues which are easier to solve (eg, network isolation during boot, IPMI security, a race condition if the data center power cycles and the node boots before the control plane is online, etc) but these are, ultimately, not enough as long as the firmware attack vector still exists.</div>
<div><br></div><div>tl;dr, We should not be recycling bare metal nodes between untrusted tenants at this time. There's a broader discussion about firmware security going on, which, I think, will take a while for the hardware vendors to really address. Fixing the other security issues around it, while good, isn't a high priority for Ironic at this time.</div>
<div><br></div><div>-Devananda </div></div></div></div>