> However, managing granular permissions for hundreds or thousands of functions is very hard to do.
When building a FaaS app from scratch granular permissions are manageable. Functions are small, so it’s easy to reason about the capabilities they need and write tight policies.
I don’t see why this doesn’t scale to a larger FaaS app.
I think the real trick is to avoid the bundling of functions and policies the article suggests people do out of convenience.
I’m working on a practical guide to Lambda and IAM policies here:
Admin'ing a system is hard work requiring a deep understanding of many different application, os and network systems, rigorous attention to detail, good communication skills and being subscribed to a variety of fractured news and alert systems to sort out what inbound patches and mitigations are relevant and what can/should be applied.
Which leads me to the point of FAAS (and other managed services like Heroku, etc). which is to let you put up a web service on the increasingly hostile and dangerous Internet without either:
- Learning all of the above (none of which is taught in a standard CS degree)
- Hiring a Sysadmin for six figures.
Any time FAAS comes up people correctly point out that a sysadmin still needs to do the work of handling the underlying OS updates, etc - which misses the point. It's the difference between flying in a 737 that's been inspected by a certified mechanic who is looking for a hundred things it would never occur for me to even consider and flown by a pilot with thousands of hours in the cockpit versus someone who flies their small aircraft a couple weekends a month and does their own inspections.
In general, I trust that the security and SRE teams at Google, AWS, Microsoft who are the main people deploying building out these FAAS systems have a better handle on these things than whoever is handling sysadmin tasks on random VPS.
I have no doubt the operators of those networks do - on average - a far better job operating the systems. My concern is that FaaS developers would therefore consider FaaS naturally secure, and forget there are still quite a few security risks they have to tackle themselves.
OS and server stack updates aren’t a case of “more secure”. Somebody still needs to do that work, and you’re trading the responsibility of doing it for the promise that somebody else will (often with no visibility into how and when).
DoS is only “solved” by “infinite capacity” insofar as you’re willing to pay for the capacity. If you have any spending caps in place, you’ll be DoSed by burning through your budget. DoS protecting must happen at a lower level than that.
The fact OS patching is done by people whose entire job and profession is to keep systems patched matters - they are patched more often and faster. In addition, the fact servers don't live long means it's easier to patch servers (since there's no need to patch a running system). So there's a very real difference here.
as a system administrator, I find the summary as laughable as the FAAS movement itself.
"FaaS takes on the responsibility for “patching” the underlying servers, freeing you from OS patching"
So a sysadm-er, devops admin will be rolling these out and back with CI on a regular basis to dev,test and prod.
"Denial of Service (DoS) attacks are naturally thwarted by the (presumed) infinite capacity Serverless offers."
Unless youre invoicing department is cutting cheques to cloudflare, you'd be surprised just how limited the service is. Capacity might be amorphously defined as infinite on paper, but network capacity is quite real.
"Since the OS is unreachable, attackers will shift their attention to the areas that remain exposed – and first amongst those would be the application itself."
the OS is reachable, what you mean to say is that its not your problem.
- A sys admin will not be rolling out OS patches. The platform does itself.
- Attackers typically use DoS to make a system unavailable, not just make it expensive to operate. I do note the cost concern, but if attackers are unsuccessful taking a system down, they are less likely to attack it.
- I indeed meant "attacking through the OS is unreachable", referring to the portion explaining the OS patches are better managed. It's indeed not perfectly accurate phrasing, but allow a guy some literal freedom in the summary - the details came before.
I don't necessarily agree with serverless thwarting DoS attacks. While technically it makes it easy to scale to accommodate the increase load (in the same way that auto-scaling will). The denial of a service is the result of your inability to pay for that "infinite" scalability.
Personally I'd much rather have to deal with my service being offline for the duration of a DoS attack, then have my company go broke from having to pay for the capacity allocated to servicing the attack.
Fair point. I see the security concern, as far as availability goes, as something FaaS improves, but it's definitely up to you to decide whether downtime is better or worse than a big bill.
Most likely way an APT compromises your service is via an infrastructure attack - e.g. having your service hacked via a phishing attack and then the APT pivots through the environment until they find the mighty AWS accounts. Server-less doesn't change that.
"Known vulnerabilities in application libraries are just as risky as those in the server dependencies, and the responsibility for addressing vulnerable app libraries falls to you – the function developer."
This isn't any different from the non-FASS world, but it is a good reminder that you still need someone doing regular maintenance.
"Since the OS is unreachable": "ideally and theoretically, the OS is behind layers of opaque abstraction and we hope nobody will find security holes to directly access it"
When building a FaaS app from scratch granular permissions are manageable. Functions are small, so it’s easy to reason about the capabilities they need and write tight policies.
I don’t see why this doesn’t scale to a larger FaaS app.
I think the real trick is to avoid the bundling of functions and policies the article suggests people do out of convenience.
I’m working on a practical guide to Lambda and IAM policies here:
https://github.com/nzoschke/gofaas/blob/master/docs/per-func...