IAM is fine, AWS IAM is needlessly complicated with garbage policies and lack of explanation.
IAM is hard – Thoughts on $80M fine from the Capital One Breach
81–90 of 125 posts
Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach
#82Earlier quoted context omitted.
That describes my own personal hell with iam, and it drove me to adopt aws-cdk. aws-cdk is their infra-as-code product and it's extremely valuable for iam alone. You can say things like: my_lambda.grantRead(s3_bucket) And it figures out the least privileges necessary to make all of that work. Plus it's real code, not some annoying DSL, which means you can easily abstract other iam permissions out. I have a fairly tig…
Cloudformation. Ewww.
Sure, CF is garbage, I won't try to argue otherwise.
There's this though: https://www.hashicorp.com/blog/cdk-for-terraform-enabling-py...
Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach
#83Earlier quoted context omitted.
So it gives a services any privilege it asks for? I haven't read the article, but from your description it doesn't sound much better than default allow-all.
It sounds a lot better. Set up your script and run it and the tool determines the minimum set of permissions needed for future runs. You lock that permission set in for future runs. Read the link
> You lock that permission set in for future runs
Thanks, that was the important bit missing from OP's description.
Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach
#84I think this is why AWS has went to recommending the multi-account model with a service per account. That model greatly limits the blast radius of misconfigured IAM in an account so that if you lose a service. You lose that services data. But almost completely block any cross application compromise. That being said multi-account can be just as difficult as IAM if you don’t properly architect for it.
Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach
#85Another reason why microservices are a good thing. They result in micro level permissions for individual resources. In saying that though, k8s in AWS was really shit at limiting what IAM roles containers could assume without it being the instance role. Crap like kube2iam and kiam came out to butcher the AWS metadata/instance networking. Thankfully AWS solved it with their new OIDC IDP. True DevOps culture workplaces…
You can just as easily give overly permissive IAM credentials to a microservice. That's what happened here. Some tiny little web service was breached, and that service was provisioned a full-access IAM credential.
If you're deploying a microservice on an individual ER2 inctance with an instance role, you're doing it wrong. Not sure where you got the idea it was a microservice. Names like a dodgy app server of some kind.
Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach
#86Earlier quoted context omitted.
You can just as easily give overly permissive IAM credentials to a microservice. That's what happened here. Some tiny little web service was breached, and that service was provisioned a full-access IAM credential.
If you're deploying a microservice on an individual ER2 inctance with an instance role, you're doing it wrong. Not sure where you got the idea it was a microservice. Names like a dodgy app server of some kind.
The point I am trying to make is "microservice" does nothing whatsoever to solve the problem of people incorrectly provisioning IAM permissions.
Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach
#87Another reason why microservices are a good thing. They result in micro level permissions for individual resources. In saying that though, k8s in AWS was really shit at limiting what IAM roles containers could assume without it being the instance role. Crap like kube2iam and kiam came out to butcher the AWS metadata/instance networking. Thankfully AWS solved it with their new OIDC IDP. True DevOps culture workplaces…
I don't see how microservices necessarily lead to what you call micro level permissions. If anything it's IAAS/PAAS and the inherent requirements that springs from that, to explicitly manage access that has started to drive this. Still, some deployment environments makes it extremely tedious to actually manage fine grained, least necessary privilege access. Especially for smaller outfits, setting up all the security…
If your microservice only updates billing details on a dynamodb table, it'll never be vulnerable to having someone take over it and stealing all the data from it.
It's what I call a micro level permission. The principal/actor can only write to one resource.
Where places get it wrong is when their application writes to dynamodb, reads from S3, does a scan on another table etc. It leads Devs to making overly permissive permissions while they debug why their app isn't working like it use to.
Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach
#88My general experience with crafting IAM policies is very reminiscent of SELinux, in that it's very difficult to work agnostically while adhering to a principle of least privilege. Especially given that this kind of task is often done by admin/ops people, one typically can't know in advance everything that the app might need to be able to access in order to work correctly. The process of discovering this is: try runni…
In our company we went the other road. We have the developers write the policies (since I mean, they know what their app needs) and test it in dev environments. After that, ops guys step in during code review to check for too broad allow in the policies. So far it seems to work in acceptable manner.
This sounds like a good process, but it depends a lot on the relationship between dev and ops... I've seen too many dev shops push against changes requested by ops or security because their main pressure is to ship features fast. And then it turns into a management fight and whoever has the more influential management gets the final say while the other side is forced to grumble.
Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach
#89but still, there are services (e.g. dom9) that implement alert and monitoring for cloud infrastructure security.
Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach
#90My general experience with crafting IAM policies is very reminiscent of SELinux, in that it's very difficult to work agnostically while adhering to a principle of least privilege. Especially given that this kind of task is often done by admin/ops people, one typically can't know in advance everything that the app might need to be able to access in order to work correctly. The process of discovering this is: try runni…
> And if you're bad, which is also not uncommon, you just give it the broadest permissions possible and call it a day.
Whether this is "bad" depends on what you're targeting... it's bad for security, but good for getting things done. And from an economic standpoint, right now, unfortunately the "good" approach is often the "bad" one.
The $80M file may be less than the cost of doing it right. And until that changes, "good" managers will incentivize the bad approach.