Ephemerality is a plus as well. Just from a security standpoint, having an ephemeral system means persistence is not possible.
> Just from a security standpoint, having an ephemeral system means persistence is not possible.
You still have to persist something somewhere, and there is a higher chance someone will figure out SQL injection or unfiltered POST request through your app than hack SSH access to the box. If someone wants to do any real damage, they'd just continuously DDoS that serverless setup, and the cloud provider will kill the company with the bill.
Is this something people are out there believing? That patching is something that's easy to automate? I find that kind of nuts, I thought everyone understood that this is, in fact, the opposite of easily automated...
> You still have to persist something somewhere, and there is a higher chance someone will figure out SQL injection or unfiltered POST request through your app than hack SSH access to the box.
"This entirely separate attack exists therefor completely removing an entire attack primitive haves no value" - how I read this comment.
It has value, but it's also true that trusting cloud providers serveless infrastructure introduces additional sets of vulnerabilities due to various reasons.
eg: https://sysdig.com/blog/exploit-mitigate-aws-lambdas-mitre/
Reading your comments, I get the impression that you are used to dealing with clients whose infrastructure management skills are lacking, and they are making a mess of things.
While serverless infrastructures certainly eliminate a range of vulnerability classes, it is adoption is unlikely to be sufficient to secure platforms that are inadequate for the threats they face.
At the end of the day, someone has to put in the work to ensure that things are patched, safe, and secure, whether the computing model is serverless or not.
I mean, I worked at Datadog when this happened: https://www.datadoghq.com/blog/engineering/2023-03-08-deep-d...
Multi-day outage because of an apt update.
Not the only one I've seen, and it's by no means the only issue that occurs with patching (extremely common that companies don't even know if they're patched for a given vuln).
Ansible on a cron, and the pipeline goes to prod if the test environment passes.
Or unattended upgrades in test, that fires a job to prod if it passes.
Or a continuous build process with Packer to replace running instances once they pass.
If you have certain things that can’t tolerate sudden downtime (a DB, etc.) then you need to know how to mask/hold those.
All this to say, it’s easy if you already know the footguns. But IMO, if you don’t know them, you don’t really have any business running Linux boxes in prod.
I am on your side, actually, I think managing machines is better than serverless, but it's not that easy.
It will happen to you sooner or later also. Updates are always out of band for this reason.
That’s why everybody does builds and isolates isolates updates to that process.
I've seen this happen twice now, as well.