IAM Notes & Role Based Deployment

"aws" supports IAM.

Temporary credentials are now supported. (For IAM/EC2 roles, see below). An additional parameter needs to be provided. The format of the --secrets-file=FILE file (default ~/.awssecret) is now:

AWS_ACCESS_KEY
AWS_SECRET_ACCESS_KEY
AWS_SESSION_IDENTIFIER

The session identifier need be provided whenever the keys are temporary keys. (The third line used to be the URL of remote signing service, but the remote signing feature has been removed.)

If you like, you can pass key pairs in environment variables. You can use either pair of variables

EC2_ACCESS_KEY=xxx EC2_SECRET_KEY=yyy aws blah blah

or

AWS_ACCESS_KEYxxx AWS_SECRET_ACCESS_KEY=yyy blah blah

The session identifier can be provided as a third environment variable AWS_SESSION_IDENTIFIER.

Many sh-like shells lets you set environment variables just like that. Otherwise, use the env command:

env AWS_ACCESS_KEYxxx AWS_SECRET_ACCESS_KEY=yyy blah blah

Both are supported to be compatible with other packages. You might take a look at the code.... Even if you don't know Perl, you should be able to understand the logic.

IAM/EC2 Roles

Define an IAM role, start an EC2 instance with that role, and then credentials become magically available. On such a server, you no longer need to create a ~/.awssecret file nor provide credentials at all. "aws" will use the credentials that are provided automatically, and you will have access to whatever resources the role allows.

You can specify a specific role using --role=ROLE, where ROLE is the name of the role, and the temporary credentials for that role will be used. Otherwise, --role (without a value) says to use whatever role was defined when the instance was launched, and those credentials are used. If no --role is specified, then the other settings are checked (--secrets-file=FILE, ~/.awssecret, etc.) as well as environment variables (see above). If no other settings yield keys, then the role that was specified when the instance was launched will be used.

For most users it means this: If you have a ~/.awssecret file, then it will be used unless you specify --role. If you have no ~/.awssecret file, then --role is assumed.

It's a lot of instructions to say that, on a server that is launched with a role, a user typically needs to do nothing related to keys... the keys are provided automatically.

Notes from Yue Liu

AWS Identity and Access Management (IAM) allows developers to manage the permissions of their resources in a finer granularity, and therefore provides stronger security. For example, our AWS account has various S3 buckets, e.g., client-data, client-credentials. We allow anyone in the development team to access client-data, but do not want to give these developers the full credentials of our AWS account, since that will expose more sensitive data, e.g., client-credentials.

In order to achieve this, we can create a IAM user under our AWS account, and set the user's permission to allow access to the bucket client-data. Then on the machines that use aws to access client-data, stores the user's credentials in ~/.awssecret. Following is a step-by-step guide of the above example.

1. Create a IAM user

2. Set the user permission as below

3. Upon finishing creating the user, the system will provide a one-time opportunity to store the credentials of the user. Copy them in ~/.awssecret on the machines where you'd like to issue aws commands: the Access Key ID on the first line and the Secret Access Key on the second line.

4. Now try fire "aws put client-data/newfle.txt ~/newfile.txt". It should just work!

Permissions:

{
    "Statement": [
        {
            "Sid": "AllowFullAccessToClientData",
            "Action": [
                "s3:*"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::client-data",
                "arn:aws:s3:::client-data/*"
            ]
        }
    ]
}