openpolitics.com

I am a cloud support engineer here at AWS, and customers often ask me how they can limit Amazon S3 bucket access to a specific AWS Identity and Access Management (IAM) role. In general, they attempt to do this the same way that they would with an IAM user: use a bucket policy to explicitly Deny all Principals (users and roles) to which they do not want to grant access. The drawback with this approach is the required maintenance of the bucket policy. If a new IAM user were added to the account with “s3:*” for the Action, the user would be granted access to the bucket. Rather than specify the list of users whose access you want to block, you can invert the logic and leverage the NotPrincipalelement in the bucket policy’s Deny statement. This element creates an explicit Deny for any user that is not listed in its value.

However, this inverted logic approach proves problematic with IAM roles because the role’s Principal value is composed of two Amazon Resource Names (ARNs), the role ARN and the assumed-role ARN. The role ARN is the identifier for the IAM role itself and the assumed-role ARN is what identifies the role session in the logs. When using the NotPrincipal element, you must include both ARNs for this approach to work, and the second of these ARNs should include a variable name. Normally you would specify a wildcard where the variable string would go, but this is not allowed in a Principal or NotPrincipal element. In this blog post, I show how you can restrict S3 bucket access to a specific IAM role or user within an account using Conditions instead of with the NotPrincipal element. Even if another user in the same account has an Admin policy or a policy with s3:*, they will be denied if they are not explicity listed. You can use this approach, for example, to configure a bucket for access by instances within an Auto Scaling group. You can also use this approach to limit access to a bucket with a high-level security need.