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

IAM Is the Worst

matduggan.com

Post reply on HN
Print view View original

11–20 of 102 posts

Re: IAM Is the Worst

#11

Post by zh3 »

IAM is hideous; users, organisations and policies are a barouque mess, where you're expected to hand-edit JSON files specifying resources then debug the cryptic error messages thrown when their own examples are pasted in.

Plus the documentation is out of date in so many places, describing actions to take that have long since changed.

It's ok for single users (simple single-user use cases) and large organisations that can afford to allocate the time and effort to administer the thing; anywhere in between is a just-say-no.

(ranting a bit because I just lost the whole morning adding a policy to allow a single user to do a limited set of things).

Re: IAM Is the Worst

#12

Post by pantulis »

I am well aware that identity and access authorisation is complex, and AWS, GCP and Azure desperately needed to add the capability to their portfolio as this is mandatory for enterprise sales which is where the big bucks are.

But boy as soon as they started adding IAM they took all the fun out of deploying my personal shit to any cloud.

Re: IAM Is the Worst

#13

Post by belter »

valenterry wrote: post #7
negus wrote: post #5

Earlier quoted context omitted.

Temporary Privileges is an example of security theater. It does not change the attack surface in a threat model because the model is not temporal. Has anyone ever shown a practical evidence that the attacker will face a problem waiting for the elevated permissions to support this idea? And if you still really want to do that, you don't need AWS roles as a separate concept for this. You can just use temporary membersh…

> Temporary Privileges is an example of a security theater. It does not change the attack surface in a threat model because it's not temporal. Has anyone ever shown a practical evidence to support this idea? I agree. I think the benefit of this is quite low. If someone takes over your machine, things are lost anyways. If they take over your machine but for some reason cannot access your password manager (or so) or yo…

Are you aware that you can associate an EC2 instance profile on a temporary basis with a role? And attach and detach them via api or on a schedule? Because if you do that, and you hack the machine (Linux, Windows or Mac not relevant...), but you don't have the role with the privileges you need, you are going nowhere.

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_us...

Re: IAM Is the Worst

#14

Post by MattPalmer1086 »

negus wrote: post #5
belter wrote: post #2

Please don't do what this article advises. These are 10 min of my life I will never get back... IAM is not that complicated. The example diagram for AWS is showing all the features available. You can use only what you require. Do two things from the beginning: 1) Least Privilege - Only the permissions required: You need to do that, because due to the constant zero days around the different software vendors, you are s…

Temporary Privileges is an example of security theater. It does not change the attack surface in a threat model because the model is not temporal. Has anyone ever shown a practical evidence that the attacker will face a problem waiting for the elevated permissions to support this idea? And if you still really want to do that, you don't need AWS roles as a separate concept for this. You can just use temporary membersh…

Why do you assert that all threat models have no temporal component?

A realistic attack that compromises a low privilege session may not be able to leverage that into higher privileges. Therefore, limiting the use of high privilege to a smaller window of time definitely reduces the attack surface.

Re: IAM Is the Worst

#15

Post by negus »

kunley wrote: post #3

That hell wouldn't exist without the guys who like to endlessly and "dutifully" set up and rearrange security groups, IAM, ldap hierarchies, just in order to feel important I guess. Every company bigger than a dozen of employees has this type of guys and they are nightmare to work with; they vision is very often detached from the reality how the company works, but somehow they have the illusion that the policy existi…

Sorry for you experience. But it not always like this. Sane security guys always remember that they are there to support the business, not to slow down the development or to prevent useful information and assets from being accessed. So they are ready to accept compromises and are always trying to control the potential risks keeping the comfort of the colleagues in mind.

Re: IAM Is the Worst

#16

Post by soco »

throwaway11460 wrote: post #9
kunley wrote: post #3

That hell wouldn't exist without the guys who like to endlessly and "dutifully" set up and rearrange security groups, IAM, ldap hierarchies, just in order to feel important I guess. Every company bigger than a dozen of employees has this type of guys and they are nightmare to work with; they vision is very often detached from the reality how the company works, but somehow they have the illusion that the policy existi…

These guys are often hired to implement regulation or certification requirements and the organization, if its goal is to comply, has to change its behavior and processes. Not saying your point is not true, I met guys who did it just because too. But it's not always malice or incompetence on their part.

My experience is that both of you are right: the security people implement important regulations, and they do so without ever looking at the business processes themselves. Then it's up to the targeted people to chase exceptions and recategorization and and and, which on one hand creates a friction which eats up lots of resources and time, and secondly pokes holes in that exact perfect structure it was supposed to create. And all this could be avoided if security worked hand in hand with business but no, security is all ivory towers and business is all "don't touch my rights". Aka, guaranteed constant conflict and frustration.

Re: IAM Is the Worst

#17

Post by orisho »

The problem with IAM systems is they tend to try to encompass so many different functionalities, and stay unopinionated, that there are just so many ways to achieve similar end results. This opens the way for endless bikeshedding, and unfortunately is inevitable to some degree in large enough organizations.

This is a bit of a shameless plug, but I hope since it's an open source project it's okay. I'm working on a suite of tools called Otterize (otter and authorize, get it, haha :) that automates workload IAM for Kubernetes workloads.

You label your Pods to get an AWS/GCP/Azure role created, and in a Kubernetes resource specify the access you need, and everything else is done by the Otterize Kubernetes operators so that your pod works.

It's a lot simpler than all the kungfu you normally have to do, but it's not magic, honestly, it's just the result of limiting scope and having an opinionated view of what the development workflow should look like. Basically, instead of maximizing on capabilities, it trades some capabilities to maximize on developer comfort.

Check it out if you're keen on contributing, or just think IAM has a tendency to devolve into a mess ridden with politics.

github.com/otterize/intents-operator and docs.otterize.com

Re: IAM Is the Worst

#18

Post by akerl_ »

negus wrote: post #5
belter wrote: post #2

Please don't do what this article advises. These are 10 min of my life I will never get back... IAM is not that complicated. The example diagram for AWS is showing all the features available. You can use only what you require. Do two things from the beginning: 1) Least Privilege - Only the permissions required: You need to do that, because due to the constant zero days around the different software vendors, you are s…

Temporary Privileges is an example of security theater. It does not change the attack surface in a threat model because the model is not temporal. Has anyone ever shown a practical evidence that the attacker will face a problem waiting for the elevated permissions to support this idea? And if you still really want to do that, you don't need AWS roles as a separate concept for this. You can just use temporary membersh…

> waiting for the elevated permissions

I think you’re talking about something different. AWS session tokens let you use your SSO to request session tokens that have a short expiry. So you can do API/console actions but if an attacker takes the creds, they expire. It also lets you generate session tokens that only have the subset of your allowed perms that you need for that workflow.

Re: IAM Is the Worst

#19

Post by belter »

zh3 wrote: post #11

IAM is hideous; users, organisations and policies are a barouque mess, where you're expected to hand-edit JSON files specifying resources then debug the cryptic error messages thrown when their own examples are pasted in. Plus the documentation is out of date in so many places, describing actions to take that have long since changed. It's ok for single users (simple single-user use cases) and large organisations that…

You have a visual editor to create those policies since 2017 at least - https://aws.amazon.com/blogs/security/use-the-new-visual-edi...

Re: IAM Is the Worst

#20

Post by mberning »

Dealing with IAM in the context of a cloud provider is honestly a dream scenario. Imagine being responsible for it in an enterprise with thousands of users and applications. Many of these apps were written before the concept of IAM even existed.
Post reply on HN