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

51–60 of 125 posts

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

#51

Post by devonkim »

kmcquade wrote: post #42
devonkim wrote: post #31

Earlier quoted context omitted.

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.

Probably can’t be open sourced given IP under contracts but I could try to re-write it. There’s some new services in IAM that could be leveraged to make it more accurate and cheaper to use, too.

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

#52

Post by echelon »

cactus2093 wrote: post #49

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…

When infra isn't code, it's very hard to recreate. You can't possibly keep track of all the knobs changed by humans. It's easy to miss them.

I like your idea of backing manually created resources with a machine log that can be replayed. Even better if it's editable and can be turned into something more concise and documented.

Terraform is hard to read and manage. But it's better than manual, bespoke infra.

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

#53

Post by [deleted] »

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…

[deleted]

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

#54

Post by jsperx »

devonkim wrote: post #51
kmcquade wrote: post #42

Earlier quoted context omitted.

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

Probably can’t be open sourced given IP under contracts but I could try to re-write it. There’s some new services in IAM that could be leveraged to make it more accurate and cheaper to use, too.

Thank you for putting this idea in my head! I’ve been trying to get better at expressing infrastructure as code, and one of the big blockers has been how adding new services to e.g. Terraform is tough when you don’t know all their permissions they need (see also https://github.com/hashicorp/terraform/issues/2834 for example).

Using a test AWS environment to stage and then checking CloudTrail to see what was actually called would be a step forward. Having software to extract it would be even better.

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

#55

Post by dopylitty »

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.

I agree with this but I think AWS could have designed the interface for IAM policies better. There are a lot of actions where the resource has to be “”. There are also many situations where the Principal is because you’re using Conditions to restrict the access (eg by the org id).

The resources are also “typed” despite the UI being json. This leads to confusion when a policy doesn’t work because the string in the resource is of the wrong type (eg S3 bucket vs S3 object). IAM happily lets you create the policy and there might be a small warning in the console that some of your policies somewhere have invalid resources for their actions but if you’re using CloudFormation you’ll never see those warnings. It begs for an automated linter that understands the type system and can fail your merge request or highlight the code in your IDE if the policy is invalid. AFAIK CFN-lint doesn’t do this but it certainly should.

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

#56

Post by dopylitty »

ENOTTY wrote: post #18

AWS Zelkova is in theory supposed to find these sorts of issues. I haven't used it, so I'm curious what others think about it.

I went to a talk about it at Re:Invent and it does seem to solve the issue in theory but the service based on it (Access Analyzer) seems to only apply to very limited use cases.

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

#57

Post by StreamBright »

cactus2093 wrote: post #49

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…

>> 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.

This is exactly why with few of my friends started to work on a tool that uses a typed language to express IaC. We can leverage and or relations for AWS objects. One quick example. S3 resource is PublicWebsite or ForwardOnly or PrivateBucket. The individual resources then have a bunch of mandatory properties (using and relationship between them). It is much easier to read and we have reduced the number of lines of code that we need to grasp to understand a service significantly. It is also possible to remove options that you do not want to give to developers at all (for example PublicWebsite is not a required option for most teams using S3). I really liked Terraform at the beginning when I thought they are going to improve significantly over the years but it did not happen. Instead they went down the same rabbit hole many other projects, lets invent a new language to express Iac. We do not need one. ML languages are perfectly capable to capture IaC and those languages are perfect fit while HCL lacks basic expressive power resulting in seggfaults/exceptions left and right. I still remember the first time we accidentally set both forward all requests to and website for an S3 bucket and we had to debug why Terraform just crashes with a meaningless error message. Imagine when you are trying to do something security related with such a tool. Not fun.

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

#59

Post by paulz_ »

kmcquade wrote: post #42
devonkim wrote: post #31

Earlier quoted context omitted.

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.

Someone has actually been working on a project like this. While not 100% complete it's the best working one I know of. Can definitely relate to the problem being described here, especially when writing IAM policies for terraform deployments.

https://github.com/flosell/trailscraper

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

#60

Post by calmlynarczyk »

cactus2093 wrote: post #49

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…

CapOne sponsors, develops, and runs internally an open-source tool called [CloudCustodian](https://cloudcustodian.io/docs/index.html) (recently accepted into the CNCF) that analyzes cloud resources at runtime and notifies developers of items that are out of compliance. This allows you to identify issues with resources even if they drift from their templated configuration.

It's a pretty good way to manage IT infrastructure at a very large scale rather than just relying on every dev to configure their infra perfectly and check in on the web console regularly to see if AWS raised any possible issues.

Post reply on HN