Cleaning Up Dead Bodies in AWS IAM
1–10 of 69 posts
Re: Cleaning Up Dead Bodies in AWS IAM
#2At 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 sent out. Just one of many projects I did for a VP where there was no active demand for that project. VP was made redundant shortly after
Re: Cleaning Up Dead Bodies in AWS IAM
#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 generalist (depth + breadth).
Re: Cleaning Up Dead Bodies in AWS IAM
#4At 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…
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?
Re: Cleaning Up Dead Bodies in AWS IAM
#5At 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…
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?
Reducing risk, yes, but I think the VP just sat around thinking of project ideas that sound useful without asking around to see if relevant stakeholders are actually interested
Re: Cleaning Up Dead Bodies in AWS IAM
#6At 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…
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?
This is the sort of ladder-climbing VP behavior you see from someone who is too concerned about avoiding failures that they don't actually do anything productive.
Don't launch any projects in a firm direction because if they fail, it's a failure of commission. Wastes lots of time churning what-if scenarios, blocking things & generating reports no one wants in case he gets asked for them, so he can't be accused of a failure of omission.
It's the 3d chess played by someone who forgets what their actual day job is - getting shit done.
Re: Cleaning Up Dead Bodies in AWS IAM
#7>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…
You don't need to know the acronyms to understand the article. Use context clues to infer that the author's point is "traditional tools don't solve the problem I am about to present". They even expand the acronyms later in the article.
Besides, most such acronyms for classes of security tools don't actually mean much. They just represent the current flavor of the week in the security arms race.
Re: Cleaning Up Dead Bodies in AWS IAM
#8>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.
Re: Cleaning Up Dead Bodies in AWS IAM
#9>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.
Re: Cleaning Up Dead Bodies in AWS IAM
#10Earlier 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?
This is the sort of ladder-climbing VP behavior you see from someone who is too concerned about avoiding failures that they don't actually do anything productive. Don't launch any projects in a firm direction because if they fail, it's a failure of commission. Wastes lots of time churning what-if scenarios, blocking things & generating reports no one wants in case he gets asked for them, so he can't be accused of a f…
If I’ve learned anything, the only people who care about doing things are at the very, very bottom. No one up the chain actually cares about doing things. They talk about doing things, present grand slidedecks internally and at conferences about doing things, have project/product/engineering managers constantly planning on doing things and thinking about better/faster ways to do them. But really there’s an entire pyramid of people in the company just kind of keeping themselves busy while the grunts at the bottom turn out as much as their hands can muster while desperately hoping to one day be a non-doer (or move to yet another company where they’re promised they’ll _actually_ do things but really it’s the same exact company with a different logo).