3 ms·
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, bu
by staticassertion 7y ago
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.
- tptacek 7y agoWhat 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.
- fovc 7y agoI 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
- tptacek 7y agoYou 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.
- fovc 7y agoHow 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
- tptacek 7y agoYou 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.
- staticassertion 7y agoAttacker 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.
- tptacek 7y agoMy 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.
- staticassertion 7y agoOSQuery 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.