| « PreviousNext » | |
   | Did this page help you? Yes | No | Tell us about it... |
Overview of Permissions
Permissions let you specify who has access to AWS resource, and what actions they can perform on those resources. Every IAM user starts with no permissions. In other words, by default, users can do nothing, not even view their own access keys. To give a user permission to do something, you can add the permission to the user (that is, attach a policy to the user) or add the user to a group that has the desired permission.
For example, you might grant a user permission to list his or her own access keys. You might also expand that permission and also let each user create, update, and delete their own keys.
When you give permissions to a group, all users in that group get those permissions. For example, you can give the Admins group permission to perform any of the IAM actions on any of the AWS account resources. Another example: You can give the Managers group permission to describe the AWS account's Amazon EC2 instances.
User-Based and Resource-Based Permissions
Permissions can be assigned in two ways: as user-based permissions or
as resource-based permissions. User-based permissions are
attached to an IAM user, group, or role and let you specify what that user, group,
or role can do. For example, you can assign permissions to the IAM user named Bob,
stating that he has permission to use the Amazon Elastic Compute Cloud (Amazon EC2)
RunInstances action and that he has permission to get items from an
Amazon DynamoDB table named MyCompany. The user Bob might also be granted
access to manage his own IAM security credentials.
Resource-based permissions are attached to a resource like an Amazon S3 bucket or an Amazon SNS topic. They let you specify who has access to the resource and what actions they can perform on it.
The following figure illustrates both types of permissions.
A user who has specific permissions might request a resource that also has permissions attached to it. In that case, both sets of permissions are evaluated when AWS determines whether to grant access to the resource. For information about how policies are evaluated, see IAM Policy Evaluation Logic.
Note
Amazon S3 supports policies for IAM users and for resources (referred to in Amazon S3 as bucket policies. In addition, Amazon S3 supports a permission mechanism known as ACLs that's independent of IAM policies and permissions, but that can interact with it. For more information, see Access Control in the Amazon Simple Storage Service Developer Guide.
Resource Creators Do Not Automatically Have Permissions
Someone using the AWS account's security credentials has permission to perform any action on resources that belong to the account. However, this isn't true for IAM users. An IAM user might be granted access to create a resource, but the user's permissions, even for that resource, are limited to what's been explicitly granted. The user's permission can be revoked at any time by the account owner or by another user who has been granted access to manage user permissions.
Granting Permissions Across AWS Accounts
You can directly grant IAM users in your own account access to your resources. If users from another account need access to your resources, you can create an IAM role, which is an entity that specifies includes permissions but that isn't associated with a specific user. Users from other accounts can then assume the role and access resources according to the permissions you've assigned to the role. For more information, see Enabling Cross-Account API Access.
Permissions For One Service to Access Another
Many AWS services access other AWS services. For example, several AWS services—including Amazon Elastic MapReduce, Elastic Load Balancing, and Auto Scaling—manage Amazon EC2 instances. Other AWS services make use of Amazon S3 buckets, Amazon SNS topics, Amazon SQS queues, and so on.
The scenario for managing permissions in these cases varies by service. Here are some examples of how permissions are handled for different services:
In Auto Scaling, users must have permission to use Auto Scaling, but don't need to be explicitly granted permission to manage Amazon EC2 instances.
In Amazon Elastic MapReduce, users need permission to access Elastic MapReduce, and must also be granted permission to manage EC2 instances. (For details, see Configure User Permissions with IAM in the Amazon Elastic MapReduce Developer Guide.)
In AWS Data Pipeline, an IAM role determines what a pipeline can do; users need permission to assume the role. (For details, see Granting Permissions to Pipelines with IAM in the AWS Data Pipeline Developer Guide.)
For details about how to configure permissions properly so that an AWS service is able to accomplish the tasks you intend, refer to the documentation for the service you are calling.
