One of the key things to remember about Fargate is the following.

Each Fargate task has its own isolation boundary and does not share the underlying kernel, CPU resources, memory resources, or elastic network interface with another task. (Source: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/...)

The other part is patching. We are (I work at AWS) responsible for patching the underlying hosts. More details at https://docs.aws.amazon.com/AmazonECS/latest/developerguide/...

> Each Fargate task has its own isolation boundary and does not share the underlying kernel, CPU resources, memory resources, or elastic network interface with another task.

Isn't Lambda the same as they're both using Firecracker under the hood isn't it?

With or without Firecracker the isolation models are similar.

Yes

Fargate solves problems like patch management, but there are other issues. If an attacker were to compromise a Fargate service they'd have less to work with, but otherwise there are a lot of advantages they'd have over EC2.

On EC2 I can deploy monitoring tools like OSQuery, or rely on audit/ other OS subsystems to monitor for suspicious behavior. On Fargate I don't think anything like this is possible.

What security problem would you be addressing with osquery that Fargate doesn't already address? If you're worried that AWS is owned up, it doesn't matter which AWS service you use.

Attacker owns my service, spawns a shell. OSQuery will tell me that a new process is running. Fargate will not tell me anything, to my knowledge.

OSQuery as a sidecar might work, if you stuff it in the container, but I doubt it can access the audit subsystem and I'm unsure if it's really been tested in that sort of environment.

I'm not concerned about container escapes or the underlying host being owned.

My take: you can run osquery in a container, but people don't, because osquery does a lot of stuff that doesn't make sense in a container environment, where you start from minimized, fine-grained control over the environment (honestly, I see a lot more productionized osquery in endpoint security than I do in serverside security). Anything you're trying to accomplish with osquery in a Fargate container, you can presumably accomplish with it or something else.

OSQuery was merely a strawman, I also mentioned the audit subsystem, but these are just implementation details.

I can not easily, in a supported fashion, track things like process executions or file interactions in a Fargate container. Maybe OSQuery could run as a sidecar, maybe auditd is actually exposed to the container, I honestly don't know.

The end result is that companies leveraging things like aws lambda or fargate are also likely giving up instrumentation that they would consider standard on EC2.

I don't think this is really controversial to say. You can absolutely justify to me that instrumentation is not worth 3rd party patch management and a nice ACL system etc.

I was thinking of this very limitation when posting the original Q. If e.g., there a RCE issue with my PHP server on Fargate, as the attacker I have a foothold and there's no monitoring inside the container as I try to move laterally. I guess the same is true with EC2 backed containers though

You can instrument the container itself (the environment in which RCE against PHP would provide an attacker).

You can't instrument the container engine or the host server, because AWS owns the security of those. But AWS will do a better job with those than you will, or at least, your whole usage of AWS is premised on that.

How often do people actually instrument their containers? I guess my original premise is wrong if you can simply set up the same monitoring inside your container

You can't do the same things; for instance, some container instrumentation schemes want an LKM to be resident, and that obviously won't work on Fargate. But you can generally accomplish the same goals.

Don't know from a Fargate perspective but Elastic Container Service (ECS) deploys EC2 servers that do not pass the CIS Benchmark. I don't believe you gain much from a security perspective.

You can roll out your own EC2 instances and Auto Scaling Group for ECS and control the security on them yourself.

This is incredibly true. The only requirement for an ECS cluster member is to be running the ECS agent - which is a Golang binary.

You're free to run a CIS hardened image if you desire to do so.

This is how we roll. CIS as base, Packer to customize (ecs agent, docker) into own AMIs.

Are there OSS or commercial AMIs that have been hardened? Maybe some RHEL or CentOS?

Yeah, if you look at the AWS image marketplace then you'll find some.

For some odd reason, I find the AWS marketplace a bit suspect looking. Not saying that it is, just that that's my impression of it.