5 ms·

Sure, but what percentage of EC2 instances do you think have a firewall rule like that? Defaults are important. Not to mention the fact that the rule you listed

Sure, but what percentage of EC2 instances do you think have a firewall rule like that? Defaults are important. Not to mention the fact that the rule you listed breaks down if you’re running docker containers.

ak217 5y ago
ECS and EKS have configurable functionality to blackhole IMDS. You can also configure IMDSv2 to have a hop limit of 1, preventing any bridged networks (such as containers) from accessing IMDS.
Spivak 5y ago
There’s no good defaults here. From AWS’s perspective the whole VM is in the same security context. It’s all untrusted customer code from the kernel on up. That’s the granularity on which policy can be applied. Either the whole VM can do something or it can’t. How you define your own security boundaries inside is your business. You can help AWS by doing your own access keys but most people would rather just also make their security boundary the VM and not have to think about it. Treat a compromised processes and a compromised host the same.
- ak217 5y ago
  That's the "give up on container and process security" approach. It's a fine approach from any given user's standpoint. From an infra/tool provider standpoint, it ignores the intense demand that exists for establishing least privilege and defense-in-depth for containerized workloads. Fargate might be a good solution too.
  - Spivak 5y ago
    This is backwards, you don't have to give up on container/process security just because AWS's own trust boundary is the VM. But to do that you can't assign VM-level privs. Something something eating cake. Put yourself in AWS's position. Your customer is running a VM which you have only hypervisor level control over. Could be Linux, could be AIX, could be an appliance. How could you possibly implement user/process level security from the outside? How could you know what processes inside the opaque black box are the privileged ones?
    - deleted 5y ago
      [deleted]
    - ak217 5y ago
      Sorry, I don't think what you're saying makes sense. A key strength of AWS is that they don't use a "black box" approach when thinking about customer needs, and provide documentation and good defaults to help customers achieve their goals.
- dotancohen 5y ago
  > From AWS’s perspective the whole VM is in the same security context. That's AWS's perspective. But my perspective, as an AWS customer, is important as well. And I might want to run something on a VM that I myself don't necessarily trust - that is the ultimate benefit of an ephemeral, isolated VM.
  - Spivak 5y ago
    Right, then you run that code in a VM that has no ambient privs. If you still need to do AWS access stuff then you just stick your access keys in files somewhere your untrusted process can't touch like if you weren't on AWS.

ak217 5y ago

ECS and EKS have configurable functionality to blackhole IMDS. You can also configure IMDSv2 to have a hop limit of 1, preventing any bridged networks (such as containers) from accessing IMDS.

Spivak 5y ago

There’s no good defaults here. From AWS’s perspective the whole VM is in the same security context. It’s all untrusted customer code from the kernel on up. That’s the granularity on which policy can be applied. Either the whole VM can do something or it can’t. How you define your own security boundaries inside is your business. You can help AWS by doing your own access keys but most people would rather just also make their security boundary the VM and not have to think about it. Treat a compromised processes and a compromised host the same.

ak217 5y ago
That's the "give up on container and process security" approach. It's a fine approach from any given user's standpoint. From an infra/tool provider standpoint, it ignores the intense demand that exists for establishing least privilege and defense-in-depth for containerized workloads. Fargate might be a good solution too.
- Spivak 5y ago
  This is backwards, you don't have to give up on container/process security just because AWS's own trust boundary is the VM. But to do that you can't assign VM-level privs. Something something eating cake. Put yourself in AWS's position. Your customer is running a VM which you have only hypervisor level control over. Could be Linux, could be AIX, could be an appliance. How could you possibly implement user/process level security from the outside? How could you know what processes inside the opaque black box are the privileged ones?
  - deleted 5y ago
    [deleted]
  - ak217 5y ago
    Sorry, I don't think what you're saying makes sense. A key strength of AWS is that they don't use a "black box" approach when thinking about customer needs, and provide documentation and good defaults to help customers achieve their goals.
dotancohen 5y ago
> From AWS’s perspective the whole VM is in the same security context. That's AWS's perspective. But my perspective, as an AWS customer, is important as well. And I might want to run something on a VM that I myself don't necessarily trust - that is the ultimate benefit of an ephemeral, isolated VM.
- Spivak 5y ago
  Right, then you run that code in a VM that has no ambient privs. If you still need to do AWS access stuff then you just stick your access keys in files somewhere your untrusted process can't touch like if you weren't on AWS.