When the doors are locked too tightly...
Or, Letting Power users change their password
This is a short post, venting some frustration with a silly AWS default, with the hopes of sparing someone else the joys.
Best security practices call for frequently changing your passwords, that's just common sense. AWS Identity and Access Management goes to the extent of providing some really cool tools to ensure that happens. IAM Roles provide a mechanism to allow software running on designated EC2 instances to retrieve "frequently" rotated access credentials. Seems like a well thought out solution to a common problem - how to let your software in EC2 securely access AWS resources, without embedding credentials in your AMI or code.
That said, allowing users to change their console password, even users whose policy is Power User. True, you should probably not really use the console... there's an API, but the default Power User template prevents all and any IAM calls, with this policy statement:
Reading around, the ""trivial"" IAM policy evaluation, well... I didn't finish. What I did end up playing with is the very useful (though not extremely intuitive) Policy Simulator (requires logging in to the management console, with very high permissions - see users and policies. I used a root account). It allows simulating performing a set of actions (from any service) by a given principal and in a given context (i.e. set variable values for those mentioned in your policies). After the fact, I ended up finding it's documentation which consists of single page with a video. Love the tool... wish it was linked into the console, and a bit easier to find. Venting over.
To reveal the end of the story, this policy allows users to modify their password:
After authoring what I thought was the right policy, I tested it on 1 user. And it didn't work. The missing incantation (no small animals harmed) was the "Version" (line 2 above). While the policy evaluation document doesn't mention it, apparently the declared version matters a lot ! Without the version, the permission didn't take affect.
Where do you get the right version you ask? Not from the API docs you don't... those still claim a version of : 2010-05-08.
Fortunately, there's an example page that lends a hand.
This is a short post, venting some frustration with a silly AWS default, with the hopes of sparing someone else the joys.
Best security practices call for frequently changing your passwords, that's just common sense. AWS Identity and Access Management goes to the extent of providing some really cool tools to ensure that happens. IAM Roles provide a mechanism to allow software running on designated EC2 instances to retrieve "frequently" rotated access credentials. Seems like a well thought out solution to a common problem - how to let your software in EC2 securely access AWS resources, without embedding credentials in your AMI or code.
That said, allowing users to change their console password, even users whose policy is Power User. True, you should probably not really use the console... there's an API, but the default Power User template prevents all and any IAM calls, with this policy statement:
Reading around, the ""trivial"" IAM policy evaluation, well... I didn't finish. What I did end up playing with is the very useful (though not extremely intuitive) Policy Simulator (requires logging in to the management console, with very high permissions - see users and policies. I used a root account). It allows simulating performing a set of actions (from any service) by a given principal and in a given context (i.e. set variable values for those mentioned in your policies). After the fact, I ended up finding it's documentation which consists of single page with a video. Love the tool... wish it was linked into the console, and a bit easier to find. Venting over.
To reveal the end of the story, this policy allows users to modify their password:
After authoring what I thought was the right policy, I tested it on 1 user. And it didn't work. The missing incantation (no small animals harmed) was the "Version" (line 2 above). While the policy evaluation document doesn't mention it, apparently the declared version matters a lot ! Without the version, the permission didn't take affect.
Where do you get the right version you ask? Not from the API docs you don't... those still claim a version of : 2010-05-08.
Fortunately, there's an example page that lends a hand.
Comments
Post a Comment