At the risk of being overly reductive, isn't this exactly the expected behavior: With ECS on EC2, the EC2 VM is a security boundary, and the container is not?
Not when the documentation states (before the recent change) "a container never has access to credentials that are intended for another container that belongs to another task"
As a heavy EC2 user who hasn't used ECS, the behavior makes perfect sense as ECS is running on EC2 but unless I sat and thought about it my first instinct would be that AWS would make it "secure by default" on a container level since containers often have different permission requirements and so the container would be the security boundary.
That said, I'm guessing it would have been obvious to anyone once they start setting up IAM permissions and therefore not much of a pitfall.
So it's a good reminder, but I agree with you, maybe the article doesn't need to be so long to get to the same point.
ECS uses bog standard Linux containers. It tries hard to isolate what it can, but there are limits to what it can do that are inherent to the model.
Back when I was an AWS containers specialist SA, I used to tell customers that containers aren’t security boundaries, and should not be treated as such. VMs are much better isolation constructs.
And containers usually have no business accessing IMDS; that’s why not using v2 with a max hop count of 1 should raise a security finding by default at any customer.
Expected, yes, but it’s not something you’d necessarily think about I guess. I never thought about the containers being able to access the EC2 metadata endpoint since ECS exposes a container specific one (although they obviously could, in hindsight).
the article is a bit breathless, which seems par for the course for security blogs these days. And while "containers are not a security boundary" is evergreen and something AWS has been trumpeting since the beginning, they IMO should also try and make it a bit harder for your to get access to the host credentials.
I do know the ECS team highly indexes on maintaining backwards compatibility and minimizing migrations wherever possible, but this seems like a case where it's warranted.
Anyone who's trying to secure workloads running in any EC2 instance should know about this, there's nothing special about it being an ECS instance. You could do the same thing with EKS.
IAM is the bane of my existance. I once had to delegate spot fleet request/launch capabilities to a third party... it took me two weeks just to figure out how to add all the right permissions to make that happen without giving too much extra power.
At the risk of being overly reductive, isn't this exactly the expected behavior: With ECS on EC2, the EC2 VM is a security boundary, and the container is not?
Not when the documentation states (before the recent change) "a container never has access to credentials that are intended for another container that belongs to another task"
As a heavy EC2 user who hasn't used ECS, the behavior makes perfect sense as ECS is running on EC2 but unless I sat and thought about it my first instinct would be that AWS would make it "secure by default" on a container level since containers often have different permission requirements and so the container would be the security boundary.
That said, I'm guessing it would have been obvious to anyone once they start setting up IAM permissions and therefore not much of a pitfall.
So it's a good reminder, but I agree with you, maybe the article doesn't need to be so long to get to the same point.
ECS uses bog standard Linux containers. It tries hard to isolate what it can, but there are limits to what it can do that are inherent to the model.
Back when I was an AWS containers specialist SA, I used to tell customers that containers aren’t security boundaries, and should not be treated as such. VMs are much better isolation constructs.
And containers usually have no business accessing IMDS; that’s why not using v2 with a max hop count of 1 should raise a security finding by default at any customer.
Expected, yes, but it’s not something you’d necessarily think about I guess. I never thought about the containers being able to access the EC2 metadata endpoint since ECS exposes a container specific one (although they obviously could, in hindsight).
The recommendation to use IMDSv2 is evergreen.
the article is a bit breathless, which seems par for the course for security blogs these days. And while "containers are not a security boundary" is evergreen and something AWS has been trumpeting since the beginning, they IMO should also try and make it a bit harder for your to get access to the host credentials.
I do know the ECS team highly indexes on maintaining backwards compatibility and minimizing migrations wherever possible, but this seems like a case where it's warranted.
Anyone who's trying to secure workloads running in any EC2 instance should know about this, there's nothing special about it being an ECS instance. You could do the same thing with EKS.
IAM is the bane of my existance. I once had to delegate spot fleet request/launch capabilities to a third party... it took me two weeks just to figure out how to add all the right permissions to make that happen without giving too much extra power.