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

61–69 of 69 posts

Re: Cleaning Up Dead Bodies in AWS IAM

#61

Post by gabereiser »

steveBK123 wrote: post #21
gabereiser wrote: post #19

Earlier quoted context omitted.

You guys have it so wrong. Their job is to get you to do things. With slide decks. Presentations. Speeches. Roadmaps. Stories. Visions. Carrots. That’s their job. As well as to aggregate the litany of statuses into an über status at the end of the week/month/quarter so that their higher ups see work being done. What they do is different from what you do so you only see them not doing what you’re doing, not what they…

In a working org you are right. In many orgs measurement of work takes precedence over actually achieving work.

All hail the oracle KPIs and OKRs to save the organization and steer us towards redemption…

Re: Cleaning Up Dead Bodies in AWS IAM

#62

Post by securiy »

shortrounddev2 wrote: post #45
scarface_74 wrote: post #37

Earlier quoted context omitted.

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

IAM users are still needed in large orgs because of legacy tooling that only accepts access key ID / secret access key sigh.

Re: Cleaning Up Dead Bodies in AWS IAM

#63

Post by securiy »

cj wrote: post #9
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…

FWIW I’ve worked extensively in AWS IAM for over a decade and have never heard of half the acronyms in the article. Don’t be intimidated.

Crap, I didn't know these acronyms before either and now I've turned into a Gartner shill :sob:

Re: Cleaning Up Dead Bodies in AWS IAM

#64

Post by wpietri »

gabereiser wrote: post #60
wpietri wrote: post #31

Earlier quoted context omitted.

You're describing the theory of managerialism. Or maybe it's better to call it the dogma. But it's definitely not always the reality. Large companies have huge inertia. And these days we also have low average CEO tenure and frequent executive position changes. The upshot being that what a given executive does can be almost entirely disconnected from productive improvement without notable short-term harm to the compan…

That’s why it’s a theory and not a law. You can attempt the same management game and get wildly different results depending on the team, the ask, the tenure, you, the company, you name it. Often what works one place, doesn’t work elsewhere. Not because they lack the understanding but because of Conway’s law.

I think it's a theory because that's what's useful for the people with power to believe and have others believe. It's the same deal with any elite; their first task is to secure a tacit belief in their superiority. CEO salaries have rocketed up in recent decades. Is that because they're wildly better? I don't think so.

Re: Cleaning Up Dead Bodies in AWS IAM

#65

Post by bravetraveler »

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

Earlier quoted context omitted.

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!

Best of luck to you! I've been around them for over a decade now, and still can't commit the various services to memory.

I like to call what I do "taking the coward's way out" -- using FreeIPA

My team setup the infrastructure in question and I've been too slow to learn it. FreeIPA is nice for quick/easy deployments.

I'm not sure how well it "scales", but it's great for getting comfortable with the "Domain Language" (sorry, pun)

Re: Cleaning Up Dead Bodies in AWS IAM

#66

Post by steveBK123 »

wpietri wrote: post #64
gabereiser wrote: post #60

Earlier quoted context omitted.

That’s why it’s a theory and not a law. You can attempt the same management game and get wildly different results depending on the team, the ask, the tenure, you, the company, you name it. Often what works one place, doesn’t work elsewhere. Not because they lack the understanding but because of Conway’s law.

I think it's a theory because that's what's useful for the people with power to believe and have others believe. It's the same deal with any elite; their first task is to secure a tacit belief in their superiority. CEO salaries have rocketed up in recent decades. Is that because they're wildly better? I don't think so.

What's funny to me having watched some executive hires flame out is the runway they are given.

It's generally assumed/understood that the higher you go the more control you have, but conversely the slower any change you try to effect is. So it's sort of like the old 3 envelopes school of management joke. They get 6-12 months to settle in. Then they do a reorg to bring in their team over the next compensation cycle. Next compensation cycle their team brings in their teams, and so on. About 3 years in and then people may start taking a long hard look at the progress or lack thereof. Finally because C-suite doesn't commit fratricide, they are given a tap on the shoulder and managed out with a nice severance, a process that may take another year.

So I've been at shops where the guy at the CTO was clearly not succeeding, didn't have stakeholders buy-in, and lacked the grunts respect. Nonetheless they got 3-5 years of very fat paychecks during which they hobbled the entire org.

At the IC level I've seen people bounced within their 90 day probation.

Re: Cleaning Up Dead Bodies in AWS IAM

#67

Post by gabereiser »

steveBK123 wrote: post #66
wpietri wrote: post #64

Earlier quoted context omitted.

I think it's a theory because that's what's useful for the people with power to believe and have others believe. It's the same deal with any elite; their first task is to secure a tacit belief in their superiority. CEO salaries have rocketed up in recent decades. Is that because they're wildly better? I don't think so.

What's funny to me having watched some executive hires flame out is the runway they are given. It's generally assumed/understood that the higher you go the more control you have, but conversely the slower any change you try to effect is. So it's sort of like the old 3 envelopes school of management joke. They get 6-12 months to settle in. Then they do a reorg to bring in their team over the next compensation cycle. N…

>At the IC level I've seen people bounced within their 90 day probation.

Or worse. Yet what you just described is something I recently witnessed at a Fortune 5000. So I can corroborate your point of view entirely.

Also, I once was let go the day after coming back from Christmas vacation (planned, whole office was out) as well as let go once a couple weeks before Christmas. The more time you spend in the industry, the more BS like this you’ll come across. These incidents were 13 years apart, but it goes to show that it’s the same, no matter when.

Re: Cleaning Up Dead Bodies in AWS IAM

#68

Post by TheNewsIsHere »

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…

Sounds like a spectacular self-DDoS on your LDAP infrastructure if that thing ever got deployed too widely and ran at the same time everywhere.
Post reply on HN