> Such as? What is the material impact of a workflow or a user having too many permissions?
Security obviously https://en.wikipedia.org/wiki/Principle_of_least_privilege
Security obviously https://en.wikipedia.org/wiki/Principle_of_least_privilege
How many times have excess permissions "actually" been the problem... versus something like correct permissions with compromised credentials?
A few examples I've seen repeatedly:
* An AWS-hosted container/artifact/CI/CD application has an SSRF vulnerability that can be used to retrieve IAM instance credentials. Because micromanaging permissions is hard, and the application needs to access so much content in S3, spin up/down instances, etc. it has ec2:* and s3:. Unless the organization has created a separate AWS account for this platform specifically, it's probably game over at that point.
An internet-facing MDM solution has a code execution vulnerability. Because the vendor didn't want to document all of the individual permissions it needs, the installation instructions specify that it should run as an account with Domain Admin permissions in AD. That is definitely game over for most organizations, because even systems that don't authenticate against AD are almost always accessed from systems that do.
Micromanaging permissions is hard in a big organization. I saw it done well, years ago, in Active Directory, but it took several FTEs who were personally interested in the topic to set up and manage, and that was a traditional big business IT environment. In a startup-style free-for-all, good luck. I don't have an opinion either way on Slauth specifically, but something that generates IAM policies procedurally seems like a step in the right direction.
By the way, I have no affiliation with slauth.io (just found them today as well). I just think that https://en.wikipedia.org/wiki/Principle_of_least_privilege is something good to follow in critical systems.
If you want to hear about stories of privilege escalation there should be easy to find. I also have some on my own which I might describe in another post but essentially it was the classic - CI/CD pipeline that "thinks" it has access only to QA does a "destroy all servers" in both QA and Production because it also had access to production without knowing anything about it.
"Accidentally destroyed production database on first day of a job"