May 13, 2014

OpenStack simplified: OpenStack Training by Sean Roberts and Colin McNamara)

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.

Hooray! Everyone's a Winner!

IDC Canada published its "IDC MarketScape: Canadian Dedicated Private infrastructure as a Service 2014 Vendor Assessment" earlier this year. The figure is the MarketScape from that report. Does anyone else see anything wrong with this picture?

Before I go any further:

  1. I have not had the opportunity read the IDC Marketscape report in its entirety and, as of this writing, have been limited to vendor articles and press releases. If anyone would like to send me a copy of the $15,000 document, I'd be more than happy to read it through and reconsider what you're about to read.
  2. In fairness, IDC's MarketScape has a methodology which states that the "...criteria selection, weightings, and vendor scores represent well-researched IDC judgement about the market and specific vendors."
Unfortunately, I think that IDC Canada missed the mark in their analysis because not everyone can be a leader. This is like saying that every athlete that participates in the Olympics finishes in first place. The simple fact that all the vendors included in the report are grouped in the top right hand corner of the MarketScape figure suggests that the criteria used probably don't differentiate between the vendors sufficiently.

I would assume that subsequent versions of this report will differentiate between the vendors and provide more valuable information for readers by providing more comparative and contrasting analysis of the various offerings.

May 12, 2014

Keystone Security and Architecture Review: Keith Newstadt

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.

OpenStack Session: Security for Private Clouds (Bryan Payne)

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.