|« PreviousNext »|
|Did this page help you? Yes | No | Tell us about it...|
This section describes a simple business use case for IAM to help you understand basic ways you might implement the service to control the AWS access your users have. The use case is described at a high level, without the mechanics of how you'd use the IAM API to achieve the results you want.
The use case centers on a fictional company called Example Corp. After setting up an AWS account for Example Corp., we show two typical examples of how the company might use IAM—first, with Amazon Elastic Compute Cloud (Amazon EC2), and then with Amazon Simple Storage Service (Amazon S3).
For more information about using IAM with other services from AWS, including how to implement individual APIs, see AWS Services that Support IAM.
Joe is the founder of Example Corp. Upon starting the company, he creates his own AWS account and he uses AWS products by himself. Then he hires employees to work as developers, admins, testers, managers, and system administrators.
Joe uses the IAM API with the AWS account's security credentials to create a user for himself called Joe, and a group called Admins. He gives the Admins group the permissions it needs to administer users, groups, and permissions for the AWS account, and he gives the Admins group permissions to perform all actions on all the AWS account's resources (for example, root privileges).
Joe creates a group called
Admins. He gives
Admins group the permissions it needs to administer users, groups, and permissions
for the AWS account, and he gives the
Admins group permissions to perform all actions
on all the AWS account's resources (for example, root privileges). He assigns
himself to the
At this point, Joe can stop using the AWS account's credentials to interact with AWS, and instead he begins using only his user credentials.
Joe also creates a group called
AllUsers so he can easily
apply any account-wide permissions to all users in the AWS account. He adds himself
to the group. He then creates a group called
Developers, a group
Testers, a group called
and a group called
SysAdmins. He creates users for each of his
employees, and puts the users in their respective groups. He also adds them all to
the AllUsers group.
For information about how to set up an Admins group, see Creating an Administrators Group Using the CLI or API. For information about creating users, see Adding an IAM User in Your AWS Account.
This use case illustrates how Example Corp. uses IAM with Amazon EC2. To understand this part of the use case, you need to have a basic understanding of Amazon EC2. For more information about Amazon EC2, go to the Amazon Elastic Compute Cloud User Guide.
To provide "perimeter" control, Joe adds a policy to the
AllUsers group that
denies any AWS request from a user if the originating IP address is outside the
Example Corp.'s corporate network.
At Example Corp., different groups require different permissions:
System Administrators—Need permission to create
and manage AMIs, instances, snapshots, volumes, security groups, and so
on. Joe adds a policy to the
SysAdmins group that gives
members of the group permission to use all the Amazon EC2 actions.
Developers—Need the ability to work with
instances only. Joe therefore adds a policy to the
Developers group that allows developers to call
Amazon EC2 uses SSH keys, Windows passwords, and security groups to control who has access to specific Amazon EC2 instances. There's no method in the IAM system to allow or deny access to a specific instance.
Managers—Should not be able to perform any EC2
actions except listing the Amazon EC2 resources currently available.
Therefore, Joe adds a policy to the
Managers group that
only lets them call Amazon EC2 "Describe" APIs.
At some point, one of the developers, Don, changes roles and becomes a manager. Joe moves
Don from the
Developers group to the
Now that he's in the
Managers group, Don's ability to interact with
Amazon EC2 instances is limited. He can't launch or start instances. He also can't
stop or terminate existing instances, even if he was the user who launched or
started the instance. He can list only the instances that Example Corp. users
This use case illustrates how Example Corp. uses IAM with Amazon S3. Joe has created an
Amazon S3 bucket for the company called
As employees, Don and Mark each need to be able to create their own data in the company's
bucket, as well as read and write shared data that all developers will work on.
To enable this, Joe logically arranges the data in
using an Amazon S3 key prefix scheme as shown in the following figure.
/example_bucket /home /don /mark /share /developers /managers
Joe divides the master
/example_bucket into a set of home directories for
each employee, and a shared area for groups of developers and managers.
Now Joe creates a set of policies to assign permissions to the users and groups:
Home directory access for Don: Joe assigns a policy to
Don that lets him read, write, and list any objects with the Amazon S3 key
Home directory access for Mark: Joe assigns a policy to
Mark that lets him read, write, and list any objects with the Amazon S3 key
Shared directory access for the Developers group: Joe
assigns a policy to the group that lets developers read, write, and list
any objects in
Shared directory access for the Managers group: Joe
assigns a policy to the group that lets managers read, write, and list
Amazon S3 doesn't automatically give a user who creates a bucket or object permission to perform other actions on that bucket or object. Therefore, in your IAM policies, you must explicitly give users permission to use the Amazon S3 resources they create.
The preceding set of policies clearly defines the actions and resources available in IAM bucket policies or bucket Access Control Lists (ACLs) when anyone in the company attempts to work on data in the corporate space. For examples of what these policies might look like, see Access Control in the Amazon Simple Storage Service Developer Guide. For information on how policies are evaluated at run time, see IAM Policy Evaluation Logic.
At some point, one of the developers, Don, changes roles and becomes a manager. We'll
assume he no longer needs access to the documents in the
share/developers directory. Joe, as an admin, moves Don to the
Managers group and out of the
With just that simple reassignment, Don automatically gets all permissions
granted to the
Managers group, but can no longer access data in the
Organizations often work with partner companies, consultants, and contractors. Example
Corp. has a partner called the Widget Company, and a Widget Company employee
named Nate needs to put data into a bucket for Example Corp.'s use. Joe creates
a group called WidgetCo and a user named
Nate and adds Nate to the
WidgetCo group. Joe also creates a special bucket called
example_partner_bucket for Nate to use.
Joe updates existing policies or adds new ones to accommodate the partner Widget Company. For example, Joe can create a new policy that denies members of the WidgetCo group the ability to use any actions other than write. This policy would be necessary only if there's a broad policy that gives all users access to a wide set of Amazon S3 actions.