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

Cleaning Up Dead Bodies in AWS IAM

noq.dev

Post reply on HN
Print view View original

41–50 of 69 posts

Re: Cleaning Up Dead Bodies in AWS IAM

#41

Post by skuenzli »

res0nat0r wrote: post #17
skuenzli wrote: post #4

Earlier quoted context omitted.

Can you share what the high-level goal of the project was? i.e. was the VP trying to reduce risk? scale out responsibility for managing access?

I'm dealing with the same type of nonsense currently, as an internal audit team sees security groups being flagged by the scanning software that are open to 0.0.0.0/0 which is automatically "bad", even though the hosts have no public IP's and are being automatically managed by EKS to setup links to k8s NodePorts and the ELB. Same with security groups. Gartner has some "best practice" doc somewhere, someone loads that…

Dumping audit reports with a sea of red on delivery teams for things largely low-risk in reality and out of their control rarely does any good.

I'm not up on EKS-ELB these days, but if the nodes only allow ingress to NodePorts from the ELB, then it seems like those findings should be suppressed in most orgs.

If the SecEng team was partnering with the delivery team they'd know that before sending the report.

Re: Cleaning Up Dead Bodies in AWS IAM

#43

Post by ams92 »

huslage wrote: post #26

This website is marketing nonsense. I need to understand the technical underpinnings of it. Why does this help me?

Managing IAM is a pain in the ass on AWS. I can’t speak to how much this product actually helps with that, but I would assume that that’s the problem they’re trying to solve.

Re: Cleaning Up Dead Bodies in AWS IAM

#44

Post by gold7777 »

beckler wrote: post #8
happytoexplain wrote: post #3

>Discover why conventional CSPM/CIEM tools fall short in cleaning up AWS IAM, and explore a better solution with Noq and IAMbic We live in a noun hell where every technical topic has a high barrier to entry that makes it hard to casually learn anything. It's difficult to be even a traditional generalist in this ecosystem, and yet the market treats people as if the only way to be considered valuable is to be a super g…

Acronyms are the worst. I guess people do it to sound cool or something, but I once maintained a legacy project that had an acronym for a name. Not a single person working at the entire company knew what the acronym originally meant, and of course, it was never documented.

15 years ago some interns where I now work created a spreadsheet and named it an acronym of their first names. That project has since developed into a fairly important system with a front end and database. They kept the name the same, of course.

Re: Cleaning Up Dead Bodies in AWS IAM

#45

Post by shortrounddev2 »

scarface_74 wrote: post #37
shortrounddev2 wrote: post #2

At my last company they asked me to find all the users who no longer needed access to our AWS account, as well as create a report for teams to review if each of their members needed access to the roles they have access to. It took a little bit to understand the IAM model, but I created dozens of reports for a few hundred engineers. Dead users were deleted, but literally nobody reviewed group access with the reports I…

Why did you have users in your AWS account besides a couple of emergency break glass users? All other users should have been going through some SSO using Microsoft AD, Okta, etc.

I did not come up with the system

Re: Cleaning Up Dead Bodies in AWS IAM

#46

Post by wpietri »

martyPort wrote: post #39
wpietri wrote: post #34

Earlier quoted context omitted.

[flagged]

You can float measures but they’re always incomplete models. I did not say all code is useless. You generalized based upon a specific conversation. Generalization I have heard over and over from speakers who, when measured, do not measure up as highly as they think they should. I am aware of various studies that measured what technologies are increasing productivity. The variables were too numerous to make meaningful…

[flagged]

Re: Cleaning Up Dead Bodies in AWS IAM

#48

Post by eddd-ddde »

bravetraveler wrote: post #38
eddd-ddde wrote: post #36

Earlier quoted context omitted.

I find interesting the last example with find and ldap queries. I'm not too familiar with ldap, but i do use find frequently. Could you expand on the example and what happens and why it's bad?

Certainly! In this case, they were interested in files that were too permissive. I don't have a good example of the command, but it was basically looking for 'worldly' permissions that were too open. It's important to note the users/groups could be discarded/ignored. They were using 'find ... -exec ls -ld {} \;' , which does an LDAP lookup on each result to resolve UIDs and GIDs to names. They could have made the pro…

Conincidentaly I just found a book in the office on understanding and deploying ldap directory services, seems like today is gonna be spent reading!

Re: Cleaning Up Dead Bodies in AWS IAM

#49

Post by martyPort »

wpietri wrote: post #46
martyPort wrote: post #39

Earlier quoted context omitted.

You can float measures but they’re always incomplete models. I did not say all code is useless. You generalized based upon a specific conversation. Generalization I have heard over and over from speakers who, when measured, do not measure up as highly as they think they should. I am aware of various studies that measured what technologies are increasing productivity. The variables were too numerous to make meaningful…

[flagged]

[flagged]
Post reply on HN