IAM is hard – Thoughts on $80M fine from the Capital One Breach
1–10 of 125 posts
Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach
#2IAM is hard; but deciding that a web proxy shouldn't have access to IAM credentials should be easy. This is why I wrote imds-filterd.
Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach
#3IAM wildcards are the new chmod 777.
Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach
#4I am not a bank. My risks are much lower. My CORS policies are strict and I block merges that are too permissive. I immediately disable and remove keys that people share in slack or emails or commits. I use IRSA everywhere I can (and net new services since I joined the current org aren't allowed to use user key pairs ever). We operate on the principal of least privilege and everything us RBAC. CapOne made a mistake and it was known. IAM is hard but when picking places to cut corners, security can't be one of them. Hopefully this fine sends that message.
Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach
#5IAM is hard; but deciding that a web proxy shouldn't have access to IAM credentials should be easy. This is why I wrote imds-filterd.
https://github.com/cperciva/imds-filterd
That's clever. The format of the config file looks pretty intuitive as well.
Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach
#6All of the AWS services I’ve used are difficult to work with. Documentation is often vague, outdated, incomplete, or nonexistent. The whole system seems designed to create jobs for AWS admins. Yes, you’ve got tons of power and control, but what we often want is transparency and simplicity, and that’s what AWS is worst at doing natively.
Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach
#7I am not a bank. My risks are much lower. My CORS policies are strict and I block merges that are too permissive. I immediately disable and remove keys that people share in slack or emails or commits. I use IRSA everywhere I can (and net new services since I joined the current org aren't allowed to use user key pairs ever). We operate on the principal of least privilege and everything us RBAC. CapOne made a mistake a…
Did they fine the management responsible for the decisions around these systems? Incentives matter. If you’re not exposed to the consequences, you’ll optimize for your comp and parachute out somewhere else when the shit hits the fan.
Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach
#8My 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 running it -- it fails, you note the permissions error -- look at docs, talk to devs, try to give it the most granular permissions it needs to get around that error -- rinse & repeat, probably many many times. This is onerous and you wind up going all around the mulberry bush trying to understand and satisfy every dependency.
At least, if you're very good and don't mind being perceived as a roadblock, you try to understand things. If you're more typical, you just find the most direct route from logged error to added permission (audit2allow approach). And if you're bad, which is also not uncommon, you just give it the broadest permissions possible and call it a day.
With respect to IAM in particular, I'm finding in the Lambda world that some seemingly straightforward functions wind up needing some sort of access to all kind of other AWS services; these services each have their own funky permissions structures and attendant quirks. Each one is a temptation to the IAM admin to just throw their hands in the air and put a wildcard on it.
Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach
#9All of the AWS services I’ve used are difficult to work with. Documentation is often vague, outdated, incomplete, or nonexistent. The whole system seems designed to create jobs for AWS admins. Yes, you’ve got tons of power and control, but what we often want is transparency and simplicity, and that’s what AWS is worst at doing natively.
I disagree on the documentation bit. I think AWS's docs are really good overall. You have the services FAQs for high level overview + AWS Docs to get deep in to the weeds.
Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach
#10All of the AWS services I’ve used are difficult to work with. Documentation is often vague, outdated, incomplete, or nonexistent. The whole system seems designed to create jobs for AWS admins. Yes, you’ve got tons of power and control, but what we often want is transparency and simplicity, and that’s what AWS is worst at doing natively.
Honestly I’ve found most AWS services hard to work with because of IAM. Though I do agree with you about the docs.