Serverless Computing: A Security Perspective | Hacker News Reader

Serverless Computing: A Security Perspective

arxiv.org

75 pointsbelter11 comments

The terminology used is a bit confusing. Execution model and application architecture are not the same dimension, so it shouldn't be a comparison between 'monolith' vs 'microservices' vs 'serverless'.

The paper seems to use 'microservices' to mean 'containers', but you can make microservices using serverless tech. Heck, you can easily run a monolith on serverless too.

Another example: the paper claims that for microservices (aka containers?), most of the security concerns remain for the app owner to deal with, whereas serverless hands much more of that off to the cloud provider. Not really true. The container-based services on GCP/AWS are almost exactly as compatible with the rest of their offerings as FaaS is. You can front container services with CDN/API gateway auth logic the same as you can for FaaS. In fact, you can do that for durable resources too.

https://arxiv.org/pdf/2107.03832.pdf

"...In this paper, we review the current serverless architectures, abstract their founding principles, and analyse them from the point of view of security. We show the security shortcomings of the analysed serverless architectural paradigms, and point to possible countermeasures..."

This is a very good analysis: there are a lot of risk with serverless computing that cannot be mitigated.

Is “serverless” an accepted term now? Seems like usage of the term generally sparks a lot of debate.

There's a misconception that containers are cconsidered "serverless."

I always thought "serverless" referred to AWS Lambda style services. Recently I saw it used to refer to cloud computing. Is this a common interpretation? It really took me by surprise.

I've always seen it to mean cases where the code owner is not responsible for designating or managing individual servers, but instead they just deploy their code and the cloud provider is responsible for scaling based on incoming load.

In that model things like AWS Lambda and Google Cloud Functions are considered serverless, but so are Elastic Beanstalk, App Engine and Cloud Run.

Managing your own individual servers in something like EC2 or Cloud Compute is definitely something I would not consider serverless, and I think most people would agree with that.

I never understood the term. 99% of computing is a client talking to some sort of server. Forgoing a server leaves just the client (which I think is what 'serverless' implies)

It doesn't mean there is no 'server' component. It's supposed to mean that the devs don't have to worry about the underlying server infrastructure that is running their code. They simply specify the code and the conditions under which it gets executed, and the serverless service takes care of running it.

I think the debate is reasonable, "serverless" (just like no-ops) implies that there are no servers (or ops minded folk), the reality is that you're outsourcing the operating system management.

For that, I think Functions-as-a-service makes more sense. Or, Containers-as-a-Service if that's your poison.

> For that, I think Functions-as-a-service makes more sense.

For internal documents I've written, I position FaaS as one category of Serverless services (which includes others like Database as a Service (DBaaS), etc.).

Reply on news.ycombinator.com