Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IAM is hard – Thoughts on $80M fine from the Capital One Breach

twitter.com

Post reply on HN
Print view View original

41–50 of 125 posts

Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach

#41

Post by erikerikson »

lostmyoldone wrote: post #35
recogepelotas wrote: post #9

Earlier quoted context omitted.

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.

They are good in some areas, but certainly not good in others. Eg when it comes to how aws codebuild/deploy and how ECS service/instance/task roles interact. It seems AWS teams are very vertical, leading to more complex cross services interaction being badly documented, as it's "nobody" who truly owns it?

Yes, their organizational structure and the lack of trust that sometimes flares up between teams really shows in the integration. Which is, of course, exactly the level where most customers live. IAM used to be exactly that but they centralized that cross-cutting concern and it's improved a lot.

Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach

#42

Post by kmcquade »

devonkim wrote: post #31
freedomben wrote: post #12

Earlier quoted context omitted.

I've seen this a ton. I have been an on/off security professional so academically I am committed to the principle of least privilege, but holy hell it can be painful or impossible in real life. Where possible I've started adopting the "run it and see" or audit2allow approach (there are awesome tools that can do this for AWS IAM perms too), but then before applying the policy, somebody needs to put a quick line beside…

Years ago I wrote a program to let various services run their course, query Cloudtrail for successful calls madero different AWS services, and attempt to find a minimal set of IAM permissions (not applicable for S3 at the time). The idea was to run an exhaustive test suite with expected allowed actions only and deny anything else. I believe AWS has a similar tool now for IAM but it’s not a problem that’ll be resolved…

Did you open source it? If not, you definitely should.

Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach

#44

Post by Trisell »

john-shaffer wrote: post #13

Those problems seem to come from the separation of the IAM admin from the developer. I'm coding a server now. My IAM roles are defined in a template, and I just add new permissions to the template as I need them. My code has the bare minimum permissions that it needs, and it doesn't seem at all onerous for the benefit it provides. So I think the problem is less "IAM is hard", and more "coordination is hard". The one…

At my company I am working to get all of our IAM policies ironed out in AWS-CDK. Through this any developer can pull down the git repo containing the IAM roles. They can makes changes and submit MRs but the only approvers of those MRs are part of our Access Management team. This all of the IAM roles can be crafted by the devs but must be explained and understood by the AM team through a code review process. After that automation takes over and then the policy can be referenced by other CDK/CF templates.

Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach

#45

Post by bobbiechen »

dasil003 wrote: post #21
john-shaffer wrote: post #13

Those problems seem to come from the separation of the IAM admin from the developer. I'm coding a server now. My IAM roles are defined in a template, and I just add new permissions to the template as I need them. My code has the bare minimum permissions that it needs, and it doesn't seem at all onerous for the benefit it provides. So I think the problem is less "IAM is hard", and more "coordination is hard". The one…

This works if all developers understand IAM and don’t just throw a wildcard in the first time they don’t understand something.

Agreed, there is a large learning curve and it took me a long time to wrap my head around it.

It requires a lot of knowledge and discipline, which sooner or later will create holes. For example, if you need to pass a role to a service, you'll need PassRole; if you grant it on " * ", then oops, you might have just created the opportunity for privilege escalation [1].

There's also probably issues specific to your company: allowing access to read resource foo in general is not an issue, except your specific company stores sensitive data there. If every developer is expected to be a security expert, the security risks increase, and the productivity overhead may even be worse than having a dedicated security/IAM team that gatekeeps permissions.

[1] https://rhinosecuritylabs.com/aws/aws-privilege-escalation-m...

Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach

#46

Post by xyzzy_plugh »

mesofile wrote: post #8

My 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…

For AWS integration with my commercial tool, I am considering having it inspect it's own permissions and loudly tell you it's misconfigured if you give it permissions to do anything more than what it minimally needs. I wish more tools did this.

Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach

#47

Post by netsectoday »

> And honestly, the problem has been so difficult to solve, that I think every AWS customer leveraging Instance Profiles or machine roles is vulnerable to this somewhere. If one app gets compromised and you haven't limited blast radius, you're screwed.

What a shit product. I loved it back when we could discuss IT infrastructure without using AWS product names.

They have infiltrated IT and the prices will continue to rise. If you took the bait; you're screwed.

They are ripping through your data (hosted on THEIR machines) to compete against you.

Here are my thoughts. IT'S A TRAP! STAY AWAY!

Re: IAM is hard – Thoughts on $80M fine from the Capital One Breach

#49

Post by cactus2093 »

One thing I find interesting is that AWS has added some safeguards to the console to protect against exactly this, since it's presumably a very common issue. As of the last couple years when you make any S3 bucket open to the world you see a big warning about it.

However if you're following the "industry best practices" and using something like Terraform to manage all your resources including IAM policies, you won't ever see the warnings. If you take a step back, it's somewhat bizarre that we've decided that having infra teams manage hundreds or thousands of lines of not-very-human-readable JSON across all the IAM resources they manage is the proper way to do things. I believe there are some linters that have some semantic understanding of IAM rules that could provide the same benefits, but at least when I last looked into it they weren't very mature and didn't match all of AWS' own rules.

After experiencing some of the pains of managing a large Terraform configuration in the past, I've definitely started to wonder if we take the idea of "infrastructure as code" too literally. I think manually writing text-only configuration files for infrastructure should start to be seen as an anti-pattern as well, and we should mostly be working with better, more intuitive UIs for creating resources and then outputting the representation in some log format (which can then be read back by the same tool for reviewing/diffing, replayed in additional environments, rolled back, etc.)

Post reply on HN