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

31–40 of 125 posts

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

#31

Post by devonkim »

freedomben wrote: post #12
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…

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 satisfactorily for everyone given the combinatorics of IAM possible. Lateral movement in IAM roles and credentials is tough and even today not every action that IMO should be flagged is reported (IAM role assumption failures across accounts is silent when I checked early last year).

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

#32

Post by lostmyoldone »

tedk-42 wrote: post #20

Another 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 specs for a quite typical setup at a good granularity has a lot of the feel of writing assembler code for a mcu with a bad datasheet.

Figuring out which rights you actually need is sometimes hilariously convoluted, as examples often use excessively large scopes, and sometimes even figuring out which service to attach them to can be extremely non-obvious.

I hope that in time there'll be tools on top of the k8s specs that takes these chores out of the equation, maybe there already are? I haven't tracked k8s closely, as it seems to mostly cater to larger outfits as of now.

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

#33

Post by mobjack »

freedomben wrote: post #12
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…

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…

The "I don't know" case is the most painful to ask for since it feels like I am always second guessed.

If I have the permission, I can tell its value in a few minutes but instead I have spend hours doing due diligence to try to justify my answer and still am not confident asking.

I usually end up getting what I need in the end so the admins don't see it as a big issue, but it is a subtle thing that can kills productivity for anything related to AWS for everyone else.

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

#34

Post by erikerikson »

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…

PureSec made a fairly useful tool:

https://github.com/puresec/serverless-puresec-cli/

There is little reason that the friction of generating least privilege IAM policies can't be reduced. The same goes for deployment Roles.

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

#35

Post by lostmyoldone »

recogepelotas wrote: post #9
grumple wrote: post #6

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

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?

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

#36

Post by kmcquade »

walterbell wrote: post #26
kmcquade wrote: post #25

Earlier quoted context omitted.

You are so right on the SELinux comparison. Of course, in this case, there are way more developers that are required to write them. Reiterating what was mentioned in the thread - the best way to avoid this wildcard situation and make it easier for developers is to use Policy Sentry[0] Thought I’d mention this for those who read the title and the comments instead of clicking on the tools. This will solve most of your…

Is there an SELinux equivalent of Policy Sentry?

I wish.

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

#37

Post by meritt »

tedk-42 wrote: post #20

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

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

#39

Post by erikerikson »

pera wrote: post #11
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.

Every time I have to read some AWS docs I get blinded by enterprise buzzwording and just want to run away...

You learn to avoid those pages. Besides, there are solid reference pages behind. I can't say the same for Azure.

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

#40

Post by heavenlyblue »

tedk-42 wrote: post #20

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

Is that a pun? :)
Post reply on HN