Multicloud Identity Isnt Ready for Prime Time

The keynote address Monday at the OpenStack Summit in Vancouver — where the world’s data center admins and engineers discuss the evolution of the data center — was ostensibly about “Connecting the Clouds to Create Huge Value.”

The idea is this: If various cloud service providers (CSPs) and on-premise data centers shared identity and access management, then end users could conduct business using huge data assets and never have to know they’re working with a half-dozen or so CSPs.

Monday’s demo seemed to make that point reasonably well. It involved a simulated movie production unit whose interests included sharing terabytes of video data securely, across clouds stationed on multiple continents, without their edits becoming the sneak preview feature on a torrent site hosted on some offshore oil rig.

“The way that TV and film [are] made is changing dramatically,” said Jonathan Bryce, the OpenStack Foundation’s executive director, in opening up this week’s Summit. He presented a graph showing the rapid growth of the film production industries in Africa and Asia, and explained that for each 44 minutes of finished content produced for television, enough footage may exist for 216,000 minutes if played sequentially end-to-end.

Borrowing Bryce’s math, that’s about 2,461 TB of video files, per program. (Add commercials and you’re probably quadrupling that figure.)


Multiple Platforms

The challenge Bryce framed is for OpenStack to not only pool that much storage, but also to manage a single train of cloud-based workflow across the multiple clouds, which coalesce to produce that pool. We’re accustomed to thinking of “the cloud” as an infinite realm of available resources, but any coalition of resources is a product of multiple platforms.

The only feasible way for those platforms to cooperate is if they can trust each other to authenticate the identities of their users and their resources, and, by default, distrust everything else.

OpenStack’s identity component is called Keystone. With the next version of OpenStack being touted at this week’s Summit, called Kilo, Keystone is slated to expand its existing identity federation to encompass what security engineers typically consider “identity federation” to be: end-to-end recognition of each other’s right to certify.


“Single source of identity, all controlled from one place,” explained the Keystone project’s team lead, HP technologist Morgan Fainberg (pictured center above). “You don’t have to worry about having every one of those sources of identity, every one of your partners, also having to have the data linked to every one of your clouds. So you can expand and contract dynamically, as needed."

The Deep, Deep Dive

At least, that’s the dream. In a “Deep Dive” panel session later that same day that perhaps should have been entitled “Small Print” instead, Fainberg quite honestly shared his views that the end goal depicted in the demo is certainly not immediately feasible for regular users.

“There are a lot of rough edges on identity federation,” the HP technologist told attendees. “We’ll be up front and say that. The really cool thing is, they’re just rough and easily polished.

“We have a lot of wish-list items we would really like to fix,” Fainberg continued, “before we tell the person who’s just getting into OpenStack and just barely scratching the surface that it’s really easy to do this. Well, it wasn’t really easy to do this.”

The panel then had a frank discussion about the remaining obstacles to their main goal, which turn out to be quite significant.

One grievance was certainly more cultural than technological, concerning the problem of personal responsibility for the job of identity validation. For now, Keystone uses an identity provision and federation protocol called Shibboleth, which dates back before the turn of the century. Shibboleth has largely been the domain of infosec professionals who are tasked with making sure people using resources are who they say they are.

In a cloud platform situation, however, “users” are more often processes than people. The act of expanding and contracting clouds as needed, which Fainberg described as vital, requires the tangible assets of cloud platforms to be authenticated to one another dynamically, which means authentication processes will happen whenever administrative changes are made to cloud configurations.

These changes raise the ire of the infosec professionals on staff, as Fainberg admitted happened in the case of his own employer, HP, where the demo was being put together. Infosec doesn’t expect such changes to happen every hour, or maybe even every month.

The Binds that Tie

But HP senior engineer Guang Yee raised a major technological problem. Shibboleth was created at a time when users existed on endpoints. In cloud platforms, intermediate components are the parts that need to be validated most, and the proxies that represent users are foremost among these components.

The relationships between users and their assets are represented in databases by bindings, and the authenticities of bindings are themselves validated, for what security engineers call, naturally enough, binding validations. These bindings made sense in a 1998 context, but not so much in 2015.

As Yee told attendees, the automation of these validations couldn’t be done using typical tools such as XML-based policies, at least not today.

“According to the documentation, it can be done through policies,” said Yee, “but what we found out is, it’s not the case, because the policy validation happened prior to the binding validation. Which means that it’s hard-coded.”

It was Yee’s very honest admission that the open source identity systems we’ve been keeping on life support since the 20th century cannot be automated in the 21st.

Snickering a bit, Yee added, “So we’re not havin’ a whole lot of choice.” Responding to a questioner, he stated that the digital signature for a binding must match an authentic endpoint, or otherwise be flagged as invalid.

Again, that makes sense in a 1998 context. But clouds aren’t stretched or contracted by their endpoints.

OpenStack engineer Jesse Keating explained the ramifications:  “So if we were to do a cloud with multiple regions, that some of our customers may want, that means we have to create relationships between each region and the identity provider, rather than having one to a complete vendor that we could assert multiples [identities] in.”

Which means, in practice today, the multi-continent cloud that Jonathan Bryce introduced Monday morning exists in the same place as consumers who make Minecraft out of their living room furniture with 3D glasses. It exists in theory.

Creative Commons Creative Commons Attribution-No Derivative Works 2.0 Generic License Title image by Shane Gorski.