Our customers use AWS in many creative and innovative ways, continuously introducing new use cases and driving us to solve unexpected and complex problems. We are constantly improving our capabilities to make sure that we support a very wide variety of use cases and access patterns.
In particular, we want to make sure that developers at any level of experience and sophistication (from a student in a dorm room to an employee of a multinational corporation) have complete control over access to their AWS resources.
AWS Identity and Access Management (IAM) lets you manage users, groups of users, and access permissions for AWS services and resources. You can also use IAM to centrally manage security credentials such as access keys, passwords, and MFA devices. Effective immediately, IAM is now a Generally Available (GA) service!
Using IAM you can create users (representing a person, an organization, or an application, as desired) within an existing AWS Account. You can also group users to apply the same set of permissions. The groups can represent functional boundaries (development vs. test), organizational boundaries (main office vs. branch office), or job function (manager, tester, developer, or system administrator). Each user can be a member of multiple groups (branch office, manager). For maximum security, newly created users have no permissions. All permission control is accomplished using policy documents containing policy statements which grant or deny access to AWS service actions or resources.
Here are some examples of the IAM command line interface in action. Let's create a user that can create and manage other users and then use this user to create a couple of additional users. Then we'll give one user the ability to access Amazon S3.
The iam-userlistbypath command lists all or some of the users in the account:
There are no default users. Let's create a user "jeff" using the iam-usercreate command ("/family" is a path that further qualifies the names):
The -k argument causes iam-usercreate to create an AWS access key (both the access key id and the secret access key) for each user. These keys are the credentials needed to access data controlled by the account. They can be inserted in to any application or tool that currently accepts an access key id and a secret access key. Note: It is important to capture and save the secret access key at this point; there's no way to retrieve it if you lose it (you can create a new set of credentials if necessary).
We can use iam-userlistbypath to verify that we now have one user:
However, user "jeff" has no access because we have not granted him any permissions. The iam-useraddpolicy command is used to add permissions to a user. The iam-groupaddpolicy command can be used to do the same for a group. Let's add a policy that gives me (user "jeff") permission to use the IAM APIs on users under the "/app" path. I might not be the only user in my account that should have this permission so I'll start by creating a group and granting the permissions to the group and then add "jeff" to the group.
I (identifying myself as user "jeff" using the credentials that I just created) can now create and manage users under the "/app" path. Let's create users for two of my applications ("syndic8" and "backup") using "/app" as the path. I can use the same command that I used to create user "jeff":
I can list only the application users I created by providing an argument to iam-userlist:
Neither "backup" nor "syndic8" have any permissions yet. I can use the access keys for user "jeff" to grant permission for the "backup" user to use all of the S3 APIs on any of my S3 resources:
This policy allows the user named "backup" to use all of the S3 APIs on any of my S3 resources, but not to access any other AWS service that my AWS Account has subscribed to.
The iam-listuserpolicies command displays the policies associated with a user; the -v option displays the contents of each policy:
So, by giving my user ("jeff") the appropriate privileges, I can minimize the use of my AWS Account credentials for access to AWS services.
You can think of the AWS Account as you would think about the Unix root (superuser) account. To get full value from IAM you should start using it when you are the only developer and you only have one application, adding users, groups, and policies as your environment becomes more complex. You can protect the AWS Account using an MFA device, and you should always sign your AWS calls using the access keys from a particular user. Once you have fully adopted IAM there should be no reason to use the AWS Account's credentials to make a call to AWS.
There are a number of other commands (fully documented in the IAM CLI Reference). Like all of the other AWS command-line tools, the IAM tools make use of the IAM APIs, all of which are documented in the IAM API Reference.
The AWS Policy Generator can be used to create policies for use with the IAM command line tools. After the policy is created it must be uploaded -- use iam-useruploadpolicy instead of iam-useraddpolicy:
IAM controls access to each service in an appropriate way. You can control access to the actions (API functions) of any supported service. You can also control access to IAM, SimpleDB, SQS, S3, SNS, and Route 53 resources. The integration is done in a seamless fashion; all of the existing APIs continue to work as expected (subject, of course, to the permissions established by the use of IAM) and there is no need to change any of the application code. You may decide to create a unique set of credentials for each application using IAM. If you do this, you'll need to embed the new credentials in each such application.
IAM currently integrates with Amazon EC2, Amazon RDS, Amazon S3, Amazon SimpleDB, Amazon SNS, Amazon SQS, Amazon VPC, Auto Scaling, Amazon Route 53, Amazon CloudFront, Amazon ElasticMapReduce, Elastic Load Balancing, AWS CloudFormation, Amazon CloudWatch, and Elastic Block Storage. IAM also integrates with itself — as you saw in my example, you can use it to give certain users or groups the ability to perform IAM actions such as creation of new users.
The AWS Account retains control of all of the data. Also, all accounting still takes place at the AWS Account level, so all usage within the account will be rolled up in to a single bill.
We have seen a wide variety of third-party tools and toolkits add support for IAM already. For example, the newest version of CloudBerry Explorer already supports IAM. Here's a screen shot of their Policy Editor:
Here are some other applications and toolkits that also support IAM:
- Boto (Python toolkit) - Complete details described in this blog post.
- Ylastic - AWS Management GUI for mobile devices.
- S3 Browser - New Bucket Sharing Wizard.
- SDB Explorer - Complete details in this blog post.
- CloudWorks - AWS Management Tool with Japanese-language UI.
- Bucket Explorer Team Edition - More info here.
Eric Hammond's article, Improving Security on EC2 With AWS Identity and Access Management (IAM), shows you how to use IAM to create a user that can create EBS snapshots and nothing more. As Eric says:
The release of AWS Identity and Access Management alleviates one of the biggest concerns security-conscious folks used to have when they started using AWS with a single key that gave complete access and control over all resources. Now the control is entirely in your hands.
The features that I have described above represent our first steps toward our long-term goals for IAM. However, we have a long (and very scenic) journey ahead of us and we are looking for additional software engineers, data engineers, development managers, technical program managers, and product managers to help us get there. If you are interested in a full-time position on the Seattle-based IAM team, please send your resume to firstname.lastname@example.org.
I think you'll agree that IAM makes AWS an even better choice for any type of deployment. As always, please feel free to leave me a comment or to send us some email.