Open Stack

Robert Collins <robertc at robertcollins.net> wrote on 05/13/2013 06:25:02 PM:


>
> Note though that the out of band IPMI network is almost certainly
> attackable by tenants. You need a chassis controller that is not
> configurable or managable by the card, to be able to have any
> confidence that it won't be hosed rapidly.
>

The operative word being 'almost'.  The problem being that it is
exceptionally difficult to know whether a vendor both considers the
scenario a priority and is competent in following through on that concern.
It pretty much demands some trusted independent organization audit vendor
implementations.  This isn't specific to IPMI of course, anything of the
same concept runs similar risks.

Almost all IPMI implementations can at least be knocked offline inband.
Quality implementations don't provide a way to gain access to the
management network in a useful way (well, you can induce the platform to
lie about alerts and throw those alerts at whatever target you want).  It
is *possible* to build a non-chassis based solution that is impervious to
being knocked out of commision inband and/or being reliably reparable in
such a case, but I don't think anyone has done it (too inconvenient as it
requires restricting things like in-band configurable passwords and network
port selection).  It might be nice to have a command for operators to be
able to use to lockdown in-band configuration.  Chassis-based solutions
might or might not be able to be knocked offline depending on vendor, but
I'd guess most at least have a way to repair the configuration from a
chassis manager regardless of configuration pushed in-band.


> -Rob
>
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Cloud Services
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130513/c0f97f43/attachment.html>