[Openstack-security] If a service is compromised, how compromised is the system?

Robert Houck houckrj at gmail.com
Wed Apr 2 15:49:02 UTC 2014


*BLUF* Since OpenStack is a distributed system, how compromised does the
system become when a single service is compromised?

*Details* I am looking at this from an insider threat, not an external
threat. Obviously, Keystone would be a 100% compromise as the thread can
create what ever token they want. In Havana, it would appear that
Ceilometer would have close to 0% on the actual operations. While billing
make be affected and usage information gathered, the system would still
operate properly.

While I have been reading up on OpenStack, I have not seen anything
detailed like this. Different policies could be implemented for each
service depending on their capabilities.

Additionally, I am looking for "flow of control" between services. I have
not found this in the documentation and would like to see what steps the
system goes through when answering a request.

While I have attempted to search the forum for similar topics, I did not
see any. I have a limited knowledge of OpenStack and may not have been
using the proper terms.

I have been looking through the Security Guide for a baseline and while
certain services are more important (messaging and keystone) or vulnerable
(nova) there isn't really a quantitative answer.

Another issue is defining how a compromise is seen. If one states a cloud
should provided Computing, Networking, and Storage (for runtime computing)
then the compromise of Swift, Neutron or Nova would mean a 100% compromise
as a removing any one of the three would prevent operations.

But one could also look at it as 33.333% for each part and one being
compromised/removed only affects 1/3 of the overall system.

I would like some professional feedback on these thoughts.


Thank you,
Robert Houck
Student, UTSA
(210) 587-9592
houckrj at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140402/1c7af31a/attachment.html>


More information about the Openstack-security mailing list