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

Follow me on Twitter: @gekart. I am a trainer and consultant for AWS, Docker, Kubernetes, Machine Learning and all things DevOps.
This entry was posted in AWS, Uncategorized and tagged , . Bookmark the permalink.