Serverless computing is the next big thing in the world of microservices and DevOps. It’s also creating some big new security challenges.
On the surface, you might think that serverless makes security much simpler from a developer’s point of view. In a serverless architecture, developers and IT Ops teams don’t have to maintain a server. The server environment and host operating system are provided for them. They just upload code and run it on demand.
In one sense, this means that the only security issues serverless computing users have to worry about are ones involving their code.
In reality, security challenges still exist. Some of them are easy to overlook.
Ignoring the issue of host security in a serverless architecture would be a mistake. It’s like thinking people who rent rather than own their house don’t have to worry about the house burning down.
Even though users don’t set up or manage the host environment in a serverless architecture, security issues within the host can still impact their applications. They need to be aware of the configuration of the host and how it could impact security for serverless functions.
Of course, this is difficult when the host infrastructure and operating system are totally managed by cloud provider rather than by the users. You’re dependent on the provider to keep the host environment secure.
Your best defense, then, is to ensure that you trust your serverless computing provider and understand the configuration of the environment as much as possible.
Alternatively, if you’re really worried about host security, you could set up your own serverless framework on servers that you control using a framework such as Fn.
Obviously, the security of your application remains entirely your responsibility when you use serverless code.
These tools can help identify some security weaknesses. But at the end of the day, developers still have to write secure code.
Locking down access control also remains developers’ and IT Ops’ responsibility in a serverless environment.
Fortunately, it is easy to do this is an effective way. One useful feature of AWS Lambda, the most popular serverless framework, is the ability to set custom IAM roles for each serverless function. This granularity can be tedious to set up and maintain, but it will do much to ensure that a security issue with one function does not compromise the entire environment.
Public-facing serverless functions are as vulnerable to DDoS attacks as any other application or service that can be accessed via the internet.
Sure, you can simply scale up your resource consumption to deal with DDoS attacks. But that would cost you a lot of money. High cost undercuts part of the value of using serverless in the first place.
DDoS threats may be one of the greatest security issues currently for serverless functions that lack a good solution. This is a challenge that providers will need to address as it grows in popularity.