Such a shallow dive: there really needs to be a lot more ink spilled on this topic in great depth. I've worked extensively with AWS over the last 4 years, and I can barely wrap my head around the scope of managing security in AWS. We have an entire department dedicated to security in our company, and none of them are remotely close to being experts in AWS security either.
I'm starting to get curious if there even is an expert who could set up and maintain a bulletproof AWS Account. From the dev/admin accounts to API Gateway to Lambda to RDS and S3; there's just too much to be an expert on. And it's all handled differently (not to mention how many times it's changed in my mere 4 years of experience).
Instances get role data from the metadata service, but containers can't access that metadata and should access the local ECS agent instead (which has its own API). Lambdas must assume a role with a dedicated policy to even write logs, but setting up a scheduled lambda adds an entire different permission object (with its own policy) just to allow the cloudwatch alert mechanism to even trigger a lambda. DB access can be authenticated using roles, but you have to manually set up the users (and their DB permissions), and it doesn't work with every DB type. S3 buckets can get policies from both built-in bucket policies and from users/roles, with inline or managed policies available for each. The API Gateway's authentication requires a Lambda function, but only passes through a single token and expects an IAM entity in response...
Even AWS' tutorials and built-in managed policies seem to throw their hands up in despair; throwing out wildcard permissions (like s3:*) left and right just to make things work.
No wonder people focus on their network and basic root account security - as frustrating and challenging as network security is, it is still a much more tractable problem.
> Instances get role data from the metadata service, but containers can't access that metadata and should access the local ECS agent instead (which has its own API).
Just a quick aside, but is this can't or shouldn't? I'm 100% positive you can use something like instance profile credentials from within a container (which loads credentials from the instance metadata service).
I think I agree that there's definitely a lot of depth to topics that should be covered here, and whether you want to go down the rabbit hole will vary based on org size and features you're using.
I'd personally prefer: 1. deep-dives into best practices for each feature as opposed to an on the surface glance.
2. enable it with examples. Include CloudFormation or Terraform scripts to set up each piece so that we actually build something. Documentation is important, but you can't learn without doing.
3. test against the security you've put in place.
Technically, shouldn't. But in AWS' documentation for container roles, they have a note that explicitly suggests implementing a iptables rule (and even provides the iptables command) to prevent access to the instance's metadata.
That said, this is another of those "more ink should be spilled" moments, since preventing access to the instance metadata is something that you SHOULD do from a security point of view.
I don't recall Task Roles being a thing when I started using EC2 Container Service. For container security and isolation, that makes a whole lot of sense.
Uh am i the only one that found none of that confusing or any more complicated than any other tech stack? Why on earth would i expect the same security process for a relational database and storage web server (s3). How is s3:* even bad? I mean clearly its a stupid default, so its not one, but a popular way amongst users to use buckets as construct for better or worse. You dont have to "throw out wildcards randomly" unless your devops situation is in shambles. Just like on any stack by any provider. Do you expect different policy expressions with any web server on earth?
It lets you do anything, including create, remove, read, update both objects and buckets. You can also change permissions on the buckets using the bucket policies.
> Why on earth would i expect the same security process
Because they do kind of use the same security process - IAM permissions. And not just DBs and S3 - all of AWS uses IAM in some way or another. But it's all just different enough to make it damned hard to create any kind of standard.
Some permissions can be fine tuned, some can not. Some can rely on conditionals, some can not. Some can be overridden at the object level, some can not. Some use roles, some users, some policies.
Understanding the differences - what works when - is what makes it all so hard to understand. And when it changes, all that knowledge is useless (or worse, dangerously incomplete) again.
This is expected. Each AWS service should be able to grow independently of each other (new features, integrations etc etc). It would be too difficult to standardize across services, instead, implement standards at a service level and maybe some more generic ones (non aws specific) outside of that.
Services should be able to grow independently. A consistent API doesn't have to prevent that. Look at Azure and GCE who don't same the same IAM rats nest.
> It lets you do anything, including create, remove, read, update both objects and buckets. You can also change permissions on the buckets using the bucket policies.
So if you don't want that, don't write it? I don't see how AWS forces anyone to make that infrastructure decision in any specific case. And its not default. You have to go out of your way to do that.
> Because they do kind of use the same security process - IAM permissions. And not just DBs and S3 - all of AWS uses IAM in some way or another. But it's all just different enough to make it damned hard to create any kind of standard.
So? The standard is running your own services and using any of the standard networking options. They are handling provisioning and networking so naturally they need an abstraction for security of network clients they are connecting for you.
> Some permissions can be fine tuned, some can not. Some can rely on conditionals, some can not. Some can be overridden at the object level, some can not. Some use roles, some users, some policies.
So? permissions, conditionals, asset policies aren't new or complicated and well within what you'd deal with in any tech stack in existence. Same goes for roles, policies, and users... Do those abstractions really seem that complicated? And in which stack do they not exist?
> Understanding the differences - what works when - is what makes it all so hard to understand. And when it changes, all that knowledge is useless (or worse, dangerously incomplete) again.
Thats fine, but arguably not better than any other service provider. You could also say those things about any software service out there - especially if its intended for consumption by engineers. Documenting APIs isn't a solved problem for anyone.
I'm starting to get curious if there even is an expert who could set up and maintain a bulletproof AWS Account. From the dev/admin accounts to API Gateway to Lambda to RDS and S3; there's just too much to be an expert on. And it's all handled differently (not to mention how many times it's changed in my mere 4 years of experience).
Instances get role data from the metadata service, but containers can't access that metadata and should access the local ECS agent instead (which has its own API). Lambdas must assume a role with a dedicated policy to even write logs, but setting up a scheduled lambda adds an entire different permission object (with its own policy) just to allow the cloudwatch alert mechanism to even trigger a lambda. DB access can be authenticated using roles, but you have to manually set up the users (and their DB permissions), and it doesn't work with every DB type. S3 buckets can get policies from both built-in bucket policies and from users/roles, with inline or managed policies available for each. The API Gateway's authentication requires a Lambda function, but only passes through a single token and expects an IAM entity in response...
Even AWS' tutorials and built-in managed policies seem to throw their hands up in despair; throwing out wildcard permissions (like s3:*) left and right just to make things work.
No wonder people focus on their network and basic root account security - as frustrating and challenging as network security is, it is still a much more tractable problem.