He is as great a contributor to the concept of cloud computing as any individual alive today. Today, Chris Kemp, the co-architect of the pioneering NASA Nebula project – the first to encapsulate a cloud server into a shipping crate – told a meeting of the Cloud Security Alliance Monday morning at the RSA Conference in San Francisco that OpenStack is, and will continue to be, designed to support other security architectures, but not to serve as one itself.
“OpenStack was really designed around common, open source technologies,” Kemp told an overflow session, “so that if you have familiarity with securing these underlying technologies, you’re going to have a fairly easy time writing security plans and implementing security and controls and monitoring around these technologies.”
Now the CEO of the commercial Nebula firm that bears the name of the NASA project he helped lead, Kemp mentioned the newest of the various components that are all integrated into the OpenStack project. OpenStack is, after all, a stack – a conglomeration of tools, resources, and techniques that collectively, and openly, enable businesses to pool compute and storage resources into private cloud architectures. One component is the Keystone identity service – which for OpenStack has been an on-again, off-again business. Just last week, Kemp said, it was on again, with a complete rewrite that includes new back-end products.
“If you’re in the identity management business, and you’ve got products in that area,” said Kemp, “we’re trying to make OpenStack much more out-of-the-box compatible with these products.” But to do this, he went on, OpenStack has adopted a plug-in architecture, so as to specifically avoid placing itself in the role of identity provider – as an authoritative source of credentials. “The intent is for OpenStack to exist in an environment where you already have some sort of identity management provider. We’re not trying to authenticate anything outside of the rest of the APIs, and we’re definitely trying to provide a common security framework for role-based access control in all the different components of OpenStack.”
Openness means friendliness – at least, that’s what implementers expect, as Kemp pointed out. Friendliness, in a technical sense, means integration. So any existing component with the facilities to integrate with Active Directory or LDAP, such as monitoring API accesses, successful and failed attempts to authenticate, logging, and correlation, should be capable of being integrated with OpenStack. He advised attendees to plan their implementation of OpenStack around how best to use their existing security information management (SIM) tools, not to change their processes to make way for it. A best-practices implementation of OpenStack, he said, would introduce no new management domains.
Knowing that, Kemp warned that OpenStack certainly does not add security where little or none exists. “Out of the box, it’s a framework and a reference implementation. It is not secure out of the box.
“Just like installing BIND on a Linux box doesn’t give you a secure DNS infrastructure, installing OpenStack out-of-the-box does not give you a scalable, secure OpenStack-based private cloud,” he emphasized. “It’s not intending to, either.” That should not dissuade careful implementers from implementing OpenStack, he added, because it does contain the building blocks for a private cloud which – when combined with best practices – can improve security and reliability.
The Cloud Security Alliance holds its annual Summit event as part of the RSA Conference, complete with its own panel session, keynote speaker, and innovator awards.