I haven't seen all of this behavior documented in a single place, so here it is.
Some of it has security implications (such as being able to brute force usernames) that is worth knowing about.
A TL;DR of the security stuff:
* Brute-forcing valid principal names is possible, since you can't create a bucket policy with an invalid principal.
* User compromise will break cross-account access, since if AWS becomes aware of a compromise, they will want you to delete the user and recreate it.
* Explicit denies will stop working if the principal is deleted and recreated, since they operate internally on the Principal ID and not the ARN
* Canonical IDs offer no extra security compared to account ARNs, since it's trivial to convert them back and get an account number.
I haven't seen all of this behavior documented in a single place, so here it is.
Some of it has security implications (such as being able to brute force usernames) that is worth knowing about.
A TL;DR of the security stuff:
* Brute-forcing valid principal names is possible, since you can't create a bucket policy with an invalid principal.
* User compromise will break cross-account access, since if AWS becomes aware of a compromise, they will want you to delete the user and recreate it.
* Explicit denies will stop working if the principal is deleted and recreated, since they operate internally on the Principal ID and not the ARN
* Canonical IDs offer no extra security compared to account ARNs, since it's trivial to convert them back and get an account number.