Live data from Hacker News

Cleaning Up Dead Bodies in AWS IAM

noq.dev

31–40 of 69 posts

Re: Cleaning Up Dead Bodies in AWS IAM

#31
post #10

Earlier quoted context omitted.

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

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…

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 company. In that kind of an environment, an ambitious executive can put the bulk of their energies to seeming effective without much worry as to actual effectiveness. Or just to indulging their personal predilections, like feeling important or in control.

Re: Cleaning Up Dead Bodies in AWS IAM

#32
post #4

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…

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?

Often creating work is a goal in itself. You gotta justify all those people somehow.

Re: Cleaning Up Dead Bodies in AWS IAM

#33

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

> They even expand the acronyms later in the article.

That's the OPPOSITE of how you're supposed to use acronyms. If you're going to spell it out anyway, why not do it the first time you talk about it like you're supposed to?

Re: Cleaning Up Dead Bodies in AWS IAM

#34

Earlier quoted context omitted.

Work is work they give me a paycheck to write code. Rather write some code than deal with a chickenshit leader who wants 100 iterations of project plans for work we will never do or generating reports that no one will ever read. Being paid to sit at a computer and not doing real work all day is more torturous than simply having actual tasks and work to do.

[flagged]

[flagged]

Re: Cleaning Up Dead Bodies in AWS IAM

#35
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…

I'm still on the platform side, out of K8s and the like - but this is so painfully true.

They try to tailor a lot of these things to the OS/distribution, but fail in the most wonderful ways.

A recent example: they're aware of RHEL. They're also aware of 'firewalld'.

However, they have not managed to realize that this is simply a management interface to other firewalls -- imposing standards on a long-deprecated backend; iptables

Meanwhile, using incredibly inefficient and 'portable' command lines. ie: using find in such a way that an LDAP query happens for every file

Refusing to use the arguments available to the operating system they 'tailor' for. Ultimately timing out once you hold a certain number of files.

Re: Cleaning Up Dead Bodies in AWS IAM

#36

Earlier quoted context omitted.

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…

I'm still on the platform side, out of K8s and the like - but this is so painfully true. They try to tailor a lot of these things to the OS/distribution, but fail in the most wonderful ways. A recent example: they're aware of RHEL. They're also aware of 'firewalld' . However, they have not managed to realize that this is simply a management interface to other firewalls -- imposing standards on a long-deprecated backe…

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?

Re: Cleaning Up Dead Bodies in AWS IAM

#37

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.

Re: Cleaning Up Dead Bodies in AWS IAM

#38

Earlier quoted context omitted.

I'm still on the platform side, out of K8s and the like - but this is so painfully true. They try to tailor a lot of these things to the OS/distribution, but fail in the most wonderful ways. A recent example: they're aware of RHEL. They're also aware of 'firewalld' . However, they have not managed to realize that this is simply a management interface to other firewalls -- imposing standards on a long-deprecated backe…

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 process far more efficient with either the native '-ls' argument built into find, or adding '-n' to the exec'd 'ls'

Either would skip the name resolution/domain. At a certain number of results/files the expense is too high, causing the job to time out

Re: Cleaning Up Dead Bodies in AWS IAM

#39
post #34

Earlier quoted context omitted.

[flagged]

[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 conclusions.

We cherry pick and make small models at jobs to obfuscate and debate who is pulling their weight. But it’s just toil to stay employed. The future value of any given for loop is zero; it’s just hustle to crank them out regardless of their use case, and denigrate others cranking out senseless reports.

There is no model that says the poster I replied to, or you, are outputting more value. It’s just toiling to make it appear so at a small scale (within the business).

14% of working adults in the US has better than a bachelors. Public opinion polls indicate the public thinks it’s almost 40% of working adults have better than a bachelors.

What your missing is how deluded the general public is about its accomplishments.

Re: Cleaning Up Dead Bodies in AWS IAM

#40

Earlier quoted context omitted.

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…

I'm still on the platform side, out of K8s and the like - but this is so painfully true. They try to tailor a lot of these things to the OS/distribution, but fail in the most wonderful ways. A recent example: they're aware of RHEL. They're also aware of 'firewalld' . However, they have not managed to realize that this is simply a management interface to other firewalls -- imposing standards on a long-deprecated backe…

[deleted]
Post reply on HN