Zum Inhalt springen

How I got AWS to update a managed IAM policy :)

Amazon/AWS people speak a lot on how they’re customer obsessed, and have a bias for action. And sometimes it sounds like talking points. But, lately, I got to experience first-hand how AWS listens (and reacts) to community feedback!

It all starts with a frustrated (IAM) user

The story is actually quite short, given how fast my feedback was taken into account.

On May 19th, I created an IAM user for a subcontractor, let’s call him John, who was supposed to work on a data lake project, so I named that user john and put him in the /datalake/ path. I set a temporary Console password and assigned the IAMUserChangePassword policy to that user.

But later that day, John gets in touch; quite pissed: „I can’t reset the password for the account you gave me, and as a result AWS won’t let me sign in„.

At first, I couldn’t understand: I had done everything by the book, didn’t I? I double-checked everything. Anyway, since John is not a very patient type, I reset his password and removed the need to update it.

But I kept digging, and then realized the IAMUserChangePassword policy was the one to blame!! At the time, its main statement read:

        {
            "Effect": "Allow",
            "Action": [
                "iam:ChangePassword"
            ],
            "Resource": [
                "arn:aws:iam::*:user/${aws:username}"
            ]
        }

And John’s IAM user ARN was not arn:aws:iam::123456789012:user/john but arn:aws:iam::123456789012:user/datalake/John, so the policy wouldn’t let him update his own password.

How fast can you take a feedback?

On May 21st at 12pm UTC, I submitted my feedback on the Community Builder community Slack channel. I was a little bit shaking: it’s not everyday you tell the IAM team they designed an incomplete IAM policy ^^

I suggested the IAM team could add arn:aws:iam::*:user/*/${aws:username} without making the policy unsafe, since IAM user names are unique (path is not considered when evaluating the uniqueness) within an AWS account.

Less than 4 hours later, a (nice) Community Manager responded that the IAM service team had considered my suggestion and found that it made sense, and would include it in a future update.

Though happy about this answer (and relieved it confirmed my judgement), I couldn’t help thinking „ok, it’s going to be delivered in 2027 at best„.

But today, while teaching an AWS course, I wanted to show my students a managed policy example, and decided to pick the IAMUserChangePassword. Here’s what I found:

IAM IAMUserChangePassword policy got updated, 8 days after I submitted my feedback

The IAM IAMUserChangePassword policy actually got updated, just 8 days after my feedback.

Ok, it’s a one-line Pull Request.
But, WOW.
In most companies, such a change request would need to be reviewed by a product owner, and validated two levels higher in the chain of command, before even reaching a developer’s desk.

My key take away: if the biggest IT company around can be this agile, then your company has no excuse ^^

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert