Open Stack

On Fri, Jan 17, 2014 at 12:35 PM, Alan Kavanagh
<alan.kavanagh at ericsson.com>wrote:

> Hi Rob
>
> 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?
>
> /Aaln
>
>
Alan,

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:

https://blueprints.launchpad.net/ironic/+spec/utility-ramdisk

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.

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.

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