I've noticed one thing that has stood out about OpenStack and that's that everyone thinks of it as open source software. Well, it is at its core, but I'd like to think of it as more than just that. Over the past 2 years, I've worked with customers who were launching new revenue streams, reinventing their business model and implementing DevOps methodologies and philosophies. So, you ask me how I think of OpenStack? I think of it as an open source IT transformation tool.
OpenStack is definitely an open source software project complete with the challenges of open source development: it's organized into projects (e.g., Nova the compute project, Neutron the networking project) which have developers that are focused on developing for that project. Releases occur every six months which means that the feature set is ever changing and improving. This means that companies that publish distributions need to keep up with them and support published versions for a period of time.
The growth of OpenStack has been interesting to watch. The number of commits have increased 10000% between 2010 and 2015. While they seem to be plateau-ing, OpenStack is seeing more and more adoption, particularly in private clouds where about half of these clouds are OpenStack based. That's not to say there aren't other high level use-cases like distributed storage for CDN-like activities, multi-site clouds or public clouds (though, admittedly, the economics of building a public cloud can be prohibitive). The OpenStack Architecture Design Guide provides additional information on these use-cases.
Given all of the above, it's easy to see why OpenStack is viewed simply as open source software. But, what they neglect to consider is what it means to deploy OpenStack within the organization:
- Bimodal IT: Gartner and other IT analyst firms have been promoting a framework that differentiates between legacy IT and the new IT ("Mode 1" and "Mode 2" in Gartner's lexicon, respectively; the difference being that Mode 1 was primarily concerned with the stability and longevity of systems whereas Mode 2 is more concerned with agility and rapid iteration). OpenStack is a Mode 2 enabling tool: it helps organizations shift their IT operations to a more dynamic model and facilitates the adoption of DevOps and PaaS.
- Transformation: Adopting Cloud is not an easy undertaking. It takes much planning to deploy it, certainly from a project perspective, but also from a governance and management perspective. The ability to manage and administer the environment is not innate in IT ops teams that tend towards Mode 1 operations; rather they require a significant will and desire to change and adapt to Mode 2 operations. OpenStack catalyzes this transformation, making it easier to adopt DevOps philosophies and PaaS deployment projects.
Essentially, OpenStack is an Open Source IT transformation tool.
Want to start out with OpenStack? Check out the FREE training guides on the OpenStack foundation site. The guides offer various levels of training ranging from beginner to architect, each guide building on the previous material.
Training available for consumption via:
- Self paced book
- Instructor led training
- Community Instructor led training
One of the most common complaints I hear from potential users, operators and customers is that OpenStack is complicated. Sean and Colin echoed this when they said that there are thousands of features released every 6 months (the development cycle of OpenStack). This training platform will go a long way to helping to demystify OpenStack based cloud computing environments and how to implement and operate them.
Still queasy at the thought of launching an internal project yourself? Find yourself an integrator. At least you'll be able to participate and truly partner with your integrator of choice.
Pertinent notes from the Keystone Security and Architecture Review at the OpenStack Summit in Atlanta, 2014.
Keystone is the gatekeeper for OpenStack and allows authentication to all OpenStack services.
Keystone:
- Is the single point of authentication for all OpenStack services
- Offers SSO to OpenStack services
- Is the common API layer on top of various authentication protocols
- Reduces exposure of credentials
Basically:
- User authenticates by sending credentials --> Keystone
- Keystone sends a token once authenticated --> User
- Keystone shares token --> OpenStack service
- Service validates identity of user via token
Users identity credentials are sent to the LDAP server that then confirms the user ID and associated roles. Services can also authenticate with Keystone and act on a user's behalf. This presents different problems that can be mitigated by securing cached credentials, limiting the scope of this delegation, expiring tokens and direct management of Keystone and OpenStack.
Of course, as with any software, Keystone has an attack surface that opens it up to spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privileges. Newstadt suggests "Supply chain management":
Download --> build --> deploy --> patch
The key is the last step to ensure that the software deployed is free of vulnerabilities.
There has also been considerable interest in using industry standards including SAML, OpenID and OAUTH because they provide SSO, improved integration, control over user credentials and a unified user experience.
Newstadt's parting thoughts:
Protect credentials everywhere. Think about how they can be attacked.Securing Keystone is an ongoing process.Share findings and ideas. This is how we'll improve Keystone and security in OpenStack.
Private clouds need security too, not just public clouds. Attack vectors are no longer limited to edge devices. "Found" USB keys loaded with malware can open up the cloud environment to attack from within an organization not to mention poorly designed security controls and policies. The bottom line is that no one wants a bot net running in their data center!
The way around this is to apply security principles to the environment. Logically separate specific use environments; make use of VPNs
Also, understanding the environment is key. Basically:
Orchestration + Known hardware = Secure infrastructure
[Applying security best practices at the outset and consistently throughout the life cycle of the environment with known hardware can help service providers (IT or actual CSPs) to protect the environment.]
Payne identified some of the biggest threats to clouds:
API endpoints
Web dashboard
Information leakage*
VM breakout*
Hardware sharing
Default images
Secondary attacks
*Easily the biggest threats according to Payne.
Information leakage can be mitigated by using TLS to protect communications between API endpoints, the web dashboard, Log feeds, AD/LDAP and external storage. VM breakouts can be basically prevented by using mandatory access controls, removing unnecessary privileges from the physical node and by hardening the build, the compiler and physical nodes.
Other attacks of concern include control plane compromise (mitigated by layered security via bi-directional firewalling, limiting data propagation, unique passwords everywhere) and upstream vulnerabilities (mitigated by security audits, aggressive security update policies).
Ultimately, cloud needs to be secure at least as everything else in the enterprise and deserves our attention. That said, I don't think we should despair because of complexity; rather, we've been through this before as web browsing, e-commerce and virtualization came into their own over the past 20 years.