[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