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

11–20 of 125 posts

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

#11

Post by pera »

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.

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

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

#12

Post by freedomben »

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 each permission that explains why. If the answer is "I don't know" and the permission is simple/low-risk then maybe let it go. If it's a high-risk permission then don't do it without answers.

That formula is the only pragmatic one I've seen. Not perfect but sometimes perfect is the enemy of good.

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

#13

Post by john-shaffer »

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 big exception I've run into is that to launch a CloudFormation template, the role practically needs admin access. I'm considering offloading the launch to a minimal Lambda function with the requisite (very broad) permissions. Does anyone have a better approach?

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

#15

Post by mobjack »

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.

My issue is that most of the examples in the documentation either have or assume lax IAM policies.

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

#16

Post by lovehashbrowns »

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…

I agree that "coordination is hard" is the root issue here. For things I develop, it's easier for me to specifically say what permissions the IAM roles need, and I can get them down to least privilege.

Then sometimes I need to onboard an application written in a language I don't know, and it's a beast of an application. I ask the developer what permissions it needs, and they say "I don't know" but give me a full admin role they know works. I'd love to go through the whole process of determining what permissions it needs, except that I have deadlines, and they have deadlines, and our deadlines are visible to management, and I have additional projects that I need to finish, and my team is already too small. It's like the universe is just telling me to give the application full admin.

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

#17

Post by donor20 »

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…

Yeah, the SELinux approach reminds me of IAM - both hard. They need to build in a run code path with full permission propose minimal policy based on accesses seen.

The reality - everyone finds it MUCH quicker to give broad admin rights out otherwise.

One good thing - accounts - you can create an account, give admin to the consultant / outsourced IT group, still bill to org, they can do what they need without endless hassle of IAM. Anyone else using this - it's a pretty rough hammer but seems to work ok so people can get solutions spun up with some efficiency.

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

#20

Post by tedk-42 »

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 have Devs writing their IAM roles as they know what services the app might talk to.

Keen to try out some tools mentioned by the twitter person

Post reply on HN