Microservices and the invasion of the identity entities

Where we apply the solution of unimpeachable identity to the new realm of microservices, and grapple with the strange philosophical dichotomies we create in the process.

171203-w3-fig-01.jpg

"Would you like to play a game?" asks the beige, boxy computer, with cheerfully glowing blue text in all-caps, vaguely like the Cheshire Cat with monochrome teeth. Matthew Broderick, once again playing the naïve adventurer, responds by dialing up global thermonuclear war, and ends up penetrating America's missile defense network.

Along with the knife stabbing through the shower curtains in Psycho, the glowing, blue-green text of the login prompt from 1983's WarGames is among the most pervasive cinematic images to transcend into popular culture. (The moral of the story -- never create a password that's a family member's name -- ended up completely ignored, but the imagery did catch on.) The nebulous barrier of the netherworld in The Matrix is a rainfall of glowing green text. Most every cable news story on cyber breaches is punctuated with a backdrop of glowing green (or maybe blue, for at least some variety) illegible text. When the subject of HPE's keynotes at its 2016 Las Vegas conference shifted from productivity to security, out went the colorful images of bustling metropolitan cities, and up came the glowing green hexadecimal digits. Even this very publication is as guilty as anyone else.

It's an indicator of how old our prevailing, popular mental image of identity on the network still is, despite everything that's happened in information technology since the early 80s: the GUI, the web, the iPhone, the cloud. The whole concept of "cyberspace" implies the occupancy by people, or entities that represent people, accessing resources, data files, and applications by moving from place to place like browsing a shopping mall. Identity is a virtue claimed first and foremost by people.

And that's the problem. For any one span of time, any enterprise's data center may be presumed to encompass every zone made available to it by the public cloud. It's a tremendous area that would include all the inanimate objects and agents rendered capable of non-directed communication through the Internet of Things, and all the microservices that fulfill functions on behalf of organizations. To ensure against any of these things being spoofed by other things, or by people, they should arguably be identified by some means.

Read also: Between the cloud and the corporate data center, there is fog computing

You could rationally assume, as many do, that you wouldn't need the same mechanism to identify things -- or, as security engineers refer to them, entities -- as you would for users who are human beings. Perhaps this will inevitably be true. But, if from an identity standpoint, entities are lesser objects than human users, it would therefore be easier for any malicious user with the smallest spot of intelligence to spoof an entity rather than a person. The weakest link in a system will be the exploited one.

171203-w3-fig-02.jpg

We find ourselves at Waypoint #3 in our four-part series, at the center of identity in the modern network. It's at the corner of our metaphorical map for a reason: Although we can plainly see a road in and out, what isn't clear yet is how we get here.

"There's going to be a lot more 'what's,'" described noted security expert and author Bruce Schneier, referring to a communications system whose ratio of entities to people will only grow. "What sent this? It's going to be a streetlight sensor that's telling me the traffic on this street is such that I'm going to try this other way. Or that I should brake now and not in fifteen milliseconds, because that'll save my life."

Letting personality get in the way

"The first thing to notice about SDP [Software-Defined Perimeter] is that it's user-centric," explained Jason Garbis, now Cyxtera's vice president for products, at the RSA 2017 security conference in San Francisco last February. Garbis showed a simple diagram of human user icons linked to a network connected to a cloud, where SDP was capable of drawing a personal perimeter around each one.

Read also: Cloud innovation will power enterprise transformation in 2018

"Each user, as they connect to the network, gets an individualized perimeter that's created for them," he continued. "That perimeter is based on the user's context, and dynamically adjusts to changes in the environment. So as the user perhaps changes from device to device, or goes from the office network to their home office location or to an airport, the system can detect that, still provide them with an appropriate level of access, but do so in a way that's adjusted based on the context."

171203-w3-fig-03.jpg

At Waypoint #2, we saw how SDP would wrap a perimeter around each user, and spawn dedicated components for each user that would uniquely protect that individual perimeter. With microservices-based distributed systems replicating services and winking them out of existence, it seems on the surface like a plausible and compatible concept.

That plausibility starts to break down under close scrutiny. The very word "identity" implies uniqueness. The very purpose of microservices is to enable multiplicity -- specifically, to enable an orchestrator to spawn as many replicas of a service as a data center may require to fulfill a job, and then to wipe them out of existence when they're no longer required. It's the job of scaling up and down, from which this blog derived its name. Services, not being unique, cannot be granted identity the way we've come to understand it.

So, if a service whose identity is challenged -- as it should be -- happens to be a firewall, that's a problem. A firewall today is any component, whether it be a software-based service or a hardware appliance, that regulates the passage of traffic between designated points in a network based on a set of rules. Managing those rules becomes quite a bit more difficult when the network's very shape is controlled by software. Imagine being a lawn mower on a planet where new tracts of turf could regenerate themselves at will.

It's a possible leak in the hard shell of SDP's basic principles. And leave it to Oracle to find a way through it.

Read also: 8 steps to becoming a 'cloud-native' enterprise

"As you think about the next-generation perimeter," Oracle group vice president for identity and cloud Rohit Gupta told ZDNet Scale, "with the network continuing to get more porous and eroding in front of us, the reality is that software represents an identity. More specifically, it represents what I believe are the breadcrumbs for what forms the perimeter. The principles of more granular segmentation of workloads, much more granular enforcement of policies, with identity at the crux of this new architecture, are really taking shape and form in front of us."

Oracle has not always been a "security company" per se, but when it has, it has oriented itself around identity. Today, the company is projecting a vision of network identity where the interweaving of countless policy-based building blocks (which Oracle does not call "entitlements") create a tightly-woven, interdependent structure that it calls a trust fabric. In this fabric, services that don't even belong to the same applications may be bound to one another through an interoperability standard. And as Oracle's Gupta points out, the wheel may not need to be reinvented here; such identity standards as OpenID and authentication standards such as OAuth already exist for this purpose.

"As you move to edge computing and the types of next-generation, highly distributed applications that essentially are gaining prevalence -- think of the IoTs of the world, and what have you -- the reality is that the lines start blurring," said Gupta, "and the concept of entity relationships start becoming important. I don't think it is identity in the traditional context that we think about. I think the principles of identity and access management start becoming relevant across this new landscape of objects and entities that interact with one another."

Though Gupta does not openly take issue with SDP, it's clear that the model he's projecting is not one that would project a new perimeter at all, either around the cloud or around any user or group of users. Instead, Oracle is touting its efforts to help its customers build what it's calling identity security operations centers (identity SOCs), which are personally manned "war rooms" where the activities of every identifiable thing is monitored. And in Gupta's vision, those things include entities.

Read also: The enterprise technologies to watch in 2017

"As enterprises consume more and more applications from the cloud, and as they're delivering many of their mission-critical services through the cloud," he said, "the reality is that the next-generation infrastructures are becoming more and more prevalent. And customers recognize the fact that their security teams are probably overburdened with monolithic tools that generate massive amounts of alerts, false positives, and things of that ilk. So a new approach is required to think about, how do you weave security into this consumption and delivery model?"

Lori MacVittie is F5 Networks' principal technical evangelist. Her career experience has been centered around modeling networks to be secure, as opposed to molding security to fit networks. In MacVittie's view, implementing the SDP vision of user identity-centric network limitation will be considerably more challenging once entities are added to the mix. What's more, the way SDP tries to resolve the access problem may conflict with the wan a different "SD" -- software-defined networking (SDN) -- addresses the issue of availability.

"The notion that you're going to restrict the network view based on my identity, sounds idyllic. This is utopia! I only see the Internet that's relevant to me," said MacVittie. "Except that one of the principles of containers and software-defined anything and cloud is that we want to abstract away the network. The network is the transport layer, and that's it. Whether I'm on this or that subnet should not really play into it, so we don't want to worry about that, because we want our little packets to be able to take the most optimal path and get where they need to be, and we want the network to be able to route around problems if they exist.

"So we don't want to necessarily restrict based on user," she went on, "because we may be unintentionally destroying our ability to access the application or the service that we're after."

MacVittie believes the eventual solution could involve categorizing the various types of entities that need to be identified differently from one another. The immediate problem she perceives with that tactic is whittling down the number of categories to a manageable handful, which may require a few years' worth of arguments among the security and containerization communities. . . who aren't exactly speaking much to each other right now.

But this would immediately create a behavioral issue among containerized environments, such as those where Docker or CoreOS provides the container and Kubernetes or Apache Mesos provides the orchestrator. At this point, API-based communications between containerized services is non-arbitrated -- meaning, there's not any intermediary or proxy (as there was for the old COM and CORBA models for service orientation in operating systems) to ensure that the entity placing the API call is authentic. That's not to say the environment isn't hardened. Docker and others do use encryption to ensure the authenticity of container images prior to their instantiation. But this kind of "hard shell / soft center" model (which security engineers call "M&Ms") does not lend itself well to entities whose lifespan and numbers of active replicas are both variables.

Read also: Microservices and containers: Eight challenges to this tech approach

Put another way: If the possible number of active instances of a particular Kubernetes pod image in a cluster at any one time is between 0 and 1,024, none of the things that identity would otherwise ensure, would be relevant here. Uniqueness is non-guaranteed. Originality is a question mark. And perhaps most importantly, provenance -- the assurance that an entity was delivered by a trusted source -- flies out the window.

Three forces are fueling microservices architectures

The microservices concept has been around for some time; what makes things so different today?

Read More

"When you start to talk about assigning identities to things, to processing components," said Trend Micro vice president for cloud research Mark Nunnikhoven, "it gets far more complex."

For an organization working with just a single cloud provider, argues Nunnikhoven, weaving security into its service as Oracle's Rohit Gupta suggested may be simple enough. (Oracle would still like to be competitive in that department, too.) Each major provider has a solution that resolves the personal identity problem. The complexity with respect to the entity identity problem, Nunnikhoven argues, works against its being resolved.

"There's limited value in it," he said. "I think our gut reaction is to identify everything, and have consistent, valid, and verifiable identities. But I think it's far more useful if you jump all the way to the data, and say, 'We've got these different ephemeral compute [entities] that scale up and down as required, but our data is still our data.' If we can assign identity and permissions at the data layer, then it's far simpler to pivot off of that, to assign identity throughout the rest of the system."

What Nunnikhoven is suggesting is a kind of reverse gateway, not for the entities and users who would conduct operations on data, but rather for the data itself. It's a trickier concept than it used to be, as the phrase "big data" suggests. Data is streamed from multiple sources, and pooled together into strange, nebulous "data lakes." But there's one advantage you can't ignore: You could definitely tell where the perimeter would go.

"This is the general approach in the data center today: When people start moving into the cloud," he told us, "they create a perimeter around their data. And they say, this application or this driver has one identity that accesses all of the data. There's no granularity in there; they say, 'It's an app, and it's in.' It's like having identity for your office, but saying, 'Everyone either has a badge or they don't.'"

Read also: 8 speed bumps that may slow down the microservices and container express

In the reverse gateway approach, firewall-like rules could limit the extent to which, or the conditions under which, certain data from particular sources may be addressable, readable, or writable. Arguably, user identities would not need to be very granularly detailed if the extent of their roles could be deduced from the limited information they did provide. Those roles could be assembled at the time data is queried, leading perhaps to complex policies that could be enforced without complex identity.

But there's also this to think about, as Bruce Schneier explained it: Leaving the identity of entities disassociated from human beings, may introduce a weakness over and above the mere strength of the certificates vouching for their existence.

"There's likely to be some liability chain somewhere," said Schneier. "If a process does something bad, we as a society will want to know who's to blame. We're going to need to know something about who started it, who programmed it, who set it up. We're going to need a 'who.' We don't need a 'who' for everything, but we'll need a 'who' for a lot of things."

The way ahead

171203-w3-fig-04.jpg

We're headed next to the distributed data center, where we'll speak to one of the leading engineers of containerized environments today -- man who genuinely believes a solution is feasible. Then, we'll examine whether AI could provide a solution we're not seeing yet: If failures could be detected, remediated, or even prevented with a machine learning system that could examine behaviors collectively, then would containers even need individual identity?

Until then, hold strong.

Journey Further -- From the CBS Interactive Network

Elsewhere

THE RACE TO THE EDGE:

Have hyperscale, will travel: How the next data center revolution starts in a toolshed

The race to the edge, part 1: Where we discover the form factor for a portable, potentially hyperscale data center, small enough to fit in the service shed beside a cell phone tower, multiplied by tens of thousands.

A data center with wings? The cloud isn't dead because the edge is portable

The race to the edge, part 2: Where we come across drones that swarm around tanker trucks like bees, and discover why they need their own content delivery network.

Edge, core, and cloud: Where all the workloads go

The race to the edge, part 4: Where we are introduced to chunks of data centers bolted onto the walls of control sheds at a wind farm, and we study the problem of how all those turbines are collected into one cloud.

It's a race to the edge, and the end of cloud computing as we know it

Our whirlwind tour of the emerging edge in data centers makes this much clear: As distributed computing evolves, there's less and less for us to comfortably ignore.

Newsletters

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
See All
See All