4 ms·

All those points are true - though I'd argue this is stretching the "one app per VM" thing -, but I guess this is just the usual case of understanding your situ

All those points are true - though I'd argue this is stretching the "one app per VM" thing -, but I guess this is just the usual case of understanding your situation and realizing there's no one size fits all. My take on this question is rather that there shouldn't be any dogma around this, such as disabling mitigations should not be considered absolutely, 100% harmful and never, ever, ever disabled. In the context of the OP, where the application is running on AWS, backups, email, etc are all likely to be handled either externally (say EBS snapshots) in which case there's no issue, or via "trusting the machine", so getting credentials via the instance role which every process on the VM can do, so no need for privilege escalation. So I guess if you trust EC2 or Task roles or similar (not familiar with EKS) to access sensitive data and only run a "single" application, there's likely little to no reason to use the mitigations. But, yeah, if you're running an application with multiple components, each in their own processes and don't use instance roles for sensitive access, maybe leave them on. Also, maybe, this means you're not running a single app per vm?

ex_amazon_sde 5y ago
Why "app"? These are services. > there shouldn't be any dogma around this Like everything in security, it's about tradeoffs. > Also, maybe, this means you're not running a single app per vm? This is an argument for unikernels. Instead, on 99.9% of your services you want to run multiple independent processes, especially in a datacenter environment: your service, web server, sshd, logging forwarder, monitoring daemon, dhcp client, NTP client, backup service. Often some additional "bigcorp" services like HIDS, credential provider, asset management, power management, deployment tools.
- vladvasiliu 5y ago
  > Why "app"? These are services. Yes, but I was using my initial post's parent's terminology. But I agree, in my mind, the subject was one single "service", as in process (or a process hierarchy, like say with gunicorn for python deployments). > This is an argument for unikernels. It is. And I'm also very interested in the developments around Firecraker and similar technologies. If we'd be able to have the kind of isolation AWS promises between ec2 instances on a single physical machine, while at the same time being able to launch a process in an isolated container as easy as with docker right now, I'd consider that really great. And all the other "infrastructure" services you talk about could just live their lives in their dedicated containers. Not sure how all this would compare, performance-wise, with just enabling the mitigations.

ex_amazon_sde 5y ago

Why "app"? These are services. > there shouldn't be any dogma around this Like everything in security, it's about tradeoffs. > Also, maybe, this means you're not running a single app per vm? This is an argument for unikernels. Instead, on 99.9% of your services you want to run multiple independent processes, especially in a datacenter environment: your service, web server, sshd, logging forwarder, monitoring daemon, dhcp client, NTP client, backup service. Often some additional "bigcorp" services like HIDS, credential provider, asset management, power management, deployment tools.

vladvasiliu 5y ago
> Why "app"? These are services. Yes, but I was using my initial post's parent's terminology. But I agree, in my mind, the subject was one single "service", as in process (or a process hierarchy, like say with gunicorn for python deployments). > This is an argument for unikernels. It is. And I'm also very interested in the developments around Firecraker and similar technologies. If we'd be able to have the kind of isolation AWS promises between ec2 instances on a single physical machine, while at the same time being able to launch a process in an isolated container as easy as with docker right now, I'd consider that really great. And all the other "infrastructure" services you talk about could just live their lives in their dedicated containers. Not sure how all this would compare, performance-wise, with just enabling the mitigations.