Jim's Depository

Until recently, you got a single identity per credit card with your Amazon Web Services (AWS) account. It you wanted to grant limited access to your S3 storage to a program or server you were pretty much out of luck.

Now, Amazon is slowly rolling out subordinate accounts, with something they call AWS Identity and Access Management (IAM). Unfortunately for you, as of March 2011 they haven’t gotten around to making the web based management interface, so you are going to get to tour a bunch of command line programs written in Java.

1. Go to IAM Getting Started Guide and start following steps to install Java and Amazon’s tools, then set a half dozen environment variables. (Go back and install sun-java6-jre if you are a Debian user, make sure non-free is in your apt source lists. Other Java implementations might work, I don’t know. And the right answer for JAVA_HOME is /usr in Debian)
2. If you get a bunch of “Unable to execute HTTP request: Network is unreachable” errors, it probably means you have a partially functional IPv6 address. You can turn your IPv6 off with  echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6 ip addr del ::¹⁄₁₂₈ dev lo
3. You don’t need to mess with groups if you don’t want to. Just use… iam-usercreate -u YOURNEWUSERNAME -k -v
4. Copy down the first two lines, that is the AWSAccessKeyId and AWSSecretKey for the new account.
5. Copy down the third line, this is the “arn” you will use to set your access.
6. Now it gets strangely painful. As near as I can tell, there is no way to reference your newly created User account in the “Grantee” section of the S3 management console, so you are going to have to delve into writing policies. You can use the policy generator to make an S3 Bucket policy. Use the “arn” you saved from line 3 as the “Principal”, set the privs you like, and for the “Resource” you can include a partial key with a “*” as a wildcard. Mine came out like this:
   { “Version”: “2008-10-17”, “Id”: “Policy1299041893976”, “Statement”: [ { “Sid”: “Stmt1299041882010”, “Effect”: “Allow”, “Principal”: { “AWS”: “arn:aws:iam::711941626500:user/MyUserName” }, “Action”: [ “s3:DeleteObject”, “s3:PutObject” ], “Resource”: “arn:aws:s3:::MyBucket/*” }, { “Sid”: “Stmt1299041882010”, “Effect”: “Allow”, “Principal”: { “AWS”: “arn:aws:iam::711941626500:user/MyUserName” }, “Action”: [ “s3:ListBucket” ], “Resource”: “arn:aws:s3::: MyBucket” } ] }   The first half gets me PUT and DELETE on objects. The second half gets me GET on the bucket. I don’t really need that, but boto needs it when I create the bucket object to then do my put.
7. Apparently Amazon engineering hates developers.
8. There is an orthogonal mechanism where you make IAM policies that grant permissions to your users. That might have made more sense, but absent a web console to view them I thought I’d go with the bucket policies.

So, there you have it. Restricted roles in your S3 account.