AWS IAM Version and SID traps

In a IAM policy JSON, if you omit the version string, you are heading for trouble:

If you do not include a Version element, the value defaults to 2008-10-17, but newer features, such as policy variables, will not work with your policy. For example, variables such as ${aws:username} aren’t recognized as variables and are instead treated as literal strings in the policy.

Therefore, “you should always include a Version element and set it to 2012-10-17.” Seen in Policy Ninja 2016.

Also interesting is the SID, that is an optional identifier, but if it is present the SID MUST be unique in the policy. So you can throw it out and don’t mind pasting a ton of statements around. Where it really becomes tricky is when you are using Ansible AWS cloud module such as lambda. There the sid is used as a statement_id that is not optional, Ansible uses it to detect create vs. update, i.e. if a specific sid is present, it will just update it instead of inserting it. Typical, configuration management behavior. But now, no one is complaining if you want to insert a new permission statement but are using the same statement_id…

About Grischa Ekart

I am a DevOps consultant writing about Docker, Kubernetes, AWS, IT, strategy, management, mobility, business cases, apps, consumer electronics and MBA education. Talk to me on Twitter: @gekart.
This entry was posted in AWS, Uncategorized and tagged , . Bookmark the permalink.