Session policies explained

gistfile1.txt

Create fine-grained session permissions using AWS Identity and Access Management (IAM) managed policies - 
I've read this three times and I still don't understand what it does. Help?

Sure, I'd be happy to help you with that. 

You use AWS STS (Simple Token Service) to assume a role and it's associated policies. So - you might call STS to assume
a role with "AdministratorAccess" policy in another account.

When you do this, you have an option to also add a "session role" on the fly - think of it as an addendum to the role.
Example, you might assume that "AdministratorAccess" role, but add in "No IAM access, please". This is handy because it
lets the caller customize the access rights it's handing out without necessarily having to have a hundred different
target roles, each with slightly different sets of rights.

Having said that, there are some fairly severe limitations on this; in particular, that the session role can only be 2048
bytes long, which turns out to be fairly constraining. 

By way of anology, think of ordering a cake from a bakery; you can say "Chocolate Birthday cake, please", and "Write 'Happy
Birthday Alice'" on top. 

What the new changes do is let you add up to 10 full-sized policies to the call, not just 1 2048 byte one. Again as an
example, you might have a "NoIAM" policy, and maybe "NoS3" or "NoRoute53" - and when you make your STS call, you can
mix-and-match all of those session policies on top of the role policy. This both lets you get a ton more complex with
what permissions you want to assign, and breaks you out of the 2048 byte complexity limit that came with on-the-fly
session policies.

Again, by way of anology, you can order a cake, and add multiple checkboxes for "filling type" and "presliced" and
"frosting" and "Plastic platypus stuck on top".