Google’s Kelsey Hightower Dissects Serverless Hype and Hope
Google’s Kelsey Hightower Dissects Serverless Hype And Hope
Serverless adoption is exploding — but what the platform is and how it might be able to help your organization depends on a lot of factors.
“Breaking down the word ‘serverless,’ for a lot of people, means almost whatever you want it to mean these days,” Kelsey Hightower, a developer advocate at Google, said during a podcast hosted by Alex Williams, founder and editor-in-chief of The New Stack that was recorded at KubeCon + CloudNativeCon North America 2018. “But I think there is this movement around so many managed services at this point and all of the problems you can solve… that you can now give it a term, a buzzword. So, that means that database now is fully managed and the security part is fully managed over the counter.”
In many ways, serverless offerings can often be reduced to the concept of offloading server-management tasks to a third party.
“We’re removing that ability or the need to think about the server,” Hightower said. “So now, you have serverless because many services are eating that world as well.”
For security, serverless also lends itself well to the “least-privilege approach,” Hightower said. “This means that if I have an app, that only needs to talk to this one database, you give it enough credentials to talk to just that one database,” Hightower said. “So, if you compromise this one server and it doesn’t have access to anything else, then you can kind of isolate it a bit.”
However, adding Kubernetes layers represents a different dynamic. “So, the cloud providers do a lot of work to make sure that all the credentials needed to do important things, are segmented from your VM or cloud functions or app engine or Kubernetes. But imagine if Kubernetes is where everything lives for you?” Hightower said. “You take Kubernetes and now you’re responsible for the whole thing, cluster wide. So, the thing that you’re doing one machine at a time, now, you’re like, ‘let’s just do it cluster wise — which we call broadening the ‘blast radius.’”
When a “blast radius” is wide, it thus becomes easier “for a whole set of machines to be taken down in one shot,” Hightower said. “So, this is where people have to be careful. Some people will say, ‘I have Kubernetes, and if I give Kubernetes keys to the castle, and I can compromise the Kubernetes API,” Hightower said. “And, yes, that’s pretty much everything just by compromising the Kubernetes API.’”
Increasing restrictions is one way to reduce Kubernetes vulnerabilities in case the wrong person gains access. “Platforms can have a lot more restrictions because they limit what you can and can’t do and what that surface looks like,” Hightower said.
For cloud functions, for example, it is possible to create a function that might only do one thing, such as “grabbing a piece of data and talking to the database,” Hightower said. “So, I’m going to launch it with security credentials that do that. Part of the platform is explicitly getting the credentials for you,” Hightower said. “[This is not about] you calling to get the credentials — I cut that off. So, I limit the attack surface.”
Hightower compared restricting access like issuing a passport — but by making sure only the right passport is given to the right person. “If I let you walk in, and you can pick any passport you want, there’s a chance you might pick the wrong one either on purpose or by mistake,” Hightower said. “Either way, it’s a security problem — I’m just going to give you your passport. So, it’s a different security model, right?”
Still, is it possible to still “go wrong on serverless?” Hightower said. “Without a doubt — but the system is a little bit well defined in ways that it limits what you can do,” Hightower said. “Anytime we had that kind of trade-off, it’s easier to secure when the surface is smaller.”
