A recent article called serverless 2.0 by trying to add statefulness to FaaS. This raised a few questions about whether or not states are good for FaaS or will it make us fall back to bad habits? To answer this question and discuss the IAM conundrum, we got Hillel Solow, CTO & Co-Founder here at Protego and Jeremy Daly, CTO of AlertMe to discuss all the latest topics in cloud-native and serverless.
Hillel asked Jeremy what he thinks about adding state to FaaS, and Jeremy was not so sure this would be good for our application development. Sure, he agreed that there is definitely a use case for stateful functions, especially in the AI and Machine Learning realms, where one does need to be able to share a fair amount of state across a number of invocations. But Jeremy is concerned about the abandonment of the paradigm shift people adopted when they started working with serverless. When you start thinking about event-driven and stateless computing, it almost forces you to build applications in a specific way, which Jeremy believes is a very good thing. What worries Jeremy in adding state to FaaS, is people might fall back on that and build serverless applications that are using old patterns, like launching WordPress in a lambda function because they can save state across.
Hillel has always been a firm believer that serverless forces developers to build applications in a way that fits and scales better in the cloud, and reconciling where state exists in those kinds of applications tends to lead to better outcomes. However, the article was striving to find the middle ground, by stating that maybe we should think of a model where there can be some sort of associate state which gets piped in and piped out of functions as well, so that scaling and ephemerality still happens, but we potentially can sacrifice the idempotency in return for some
amount of sticky state that the system will magically bring to the right function at the right time, and this could be a very interesting model.
With serverless and FaaS comes the opportunity for a more fine-grained IAM permissioning, and with that perhaps greater security. However, as Jeremy stated and Hillel agreed, IAM is hard. It’s not easy to create a centralized repository where all these different teams have some autonomy into the system where they can control access to their resources. We want to be able to take a column in a database or in a DynamoDB table, and just restrict access to that column. Maybe that’s an email address or a saved card number, but we still want to be able to provide access to some of that data. When there are sensitive bits of data, people end up breaking it up into multiple tables or into separate systems, and then try to get really fine-grained with the IAM permissions there. And that is indeed, a nightmare.
So, IAM is extremely complex and for that reason, when dealing with a large system, organizations might need an IAM master. Even then, the likelihood of human mistakes in this great pool of permissioning is enormous. If we add to it the fact that one needs to understand both security and code to get IAM right in serverless, an automated tool like Protego which provides automatic and fine-grained IAM role per function, can solve this issue for big and small systems. Jeremy believes, however, that if you are developing small applications, serverless really gives you the opportunity to figure out IAM permissions on your own.
Jeremy adds an important point when it comes to SAM .YAML and Serverless.YAML templates, that are typically created by developers. Cloud security is probably not the first thing on their mind. It certainly should be, but do they understand what the requirements are for GDPR and CCPA and all these other compliance standards? Do they understand what they need to limit? Do they have the context of the holistic security of your application? If they don’t have that, then that requires another level of checks for somebody to go and review that, and that’s when it becomes a burden.
For that and many other reasons, serverless security should be as automated as possible, and as code-centric as possible.