Overview of AWS IAM Permissions
Permissions let you specify who has access to AWS resources, 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.
For information about how to delegate basic permissions to your users, groups, and roles, see Delegating Permissions to Administer IAM Users, Groups, and Credentials. For additional examples of policies that illustrate basic permissions, see Example Policies for Administering IAM Resources.
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)
RunInstancesaction 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. User-based permissions can be managed or inline.
Resource-based permissions are attached to a resource. You can specify resource-based permissions for Amazon S3 buckets, Amazon Glacier vaults, Amazon SNS topics, Amazon SQS queues, and AWS Key Management Service encryption keys. Resource-based permissions let you specify who has access to the resource and what actions they can perform on it. Resource-based policies are inline only, not managed.
There's a difference between resource-based permissions and resource-level permissions. Resource-based permissions are permissions you can attach directly to a resource, as described in this topic. Resource-level permissions refers to the ability to specify not just what actions users can perform, but which resources they're allowed to perform those actions on. Some AWS services let you specify permissions for actions, but don't let you specify the individual resources for those actions. Other services let you specify permissions for a combination of actions and individual resources.
Resource-based permissions are supported only by some AWS services. For a list of which services support resource-level permissions, see AWS Services That Work with IAM.
The following figure illustrates both types of permissions. The first column shows permissions attached to a user instead of a resource. Some of those permissions identify specific resources that the actions can be used against. Those actions support resource-level permissions. The second column shows permissions attached to resources. Those services support resource-based permissions.
When you attach a policy to an AWS resource (including the trust policy of an IAM role), AWS validates, processes, and transforms the policy you write before storing it. When AWS returns the policy in response to a user query, AWS transforms the policy back into a human-readable format. This can result in differences in what you see in the policy: non-significant whitespace can be removed, elements within JSON maps can be re-ordered, and AWS account IDs within the Principal elements can be substituted with the ARN of the account root user. Because of these possible changes, you should not compare JSON policies documents as strings.
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.
Amazon S3 supports policies both for IAM users and for resources (referred to in Amazon S3 as bucket policies). In addition, Amazon S3 supports a permission mechanism known as an ACL that's independent of IAM policies and permissions. You can use IAM policies in combination with Amazon S3 ACLs. 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 includes permissions but that isn't associated with a specific user. Users from other accounts can then use the role and access resources according to the permissions you've assigned to the role. For more information, see IAM Roles.
For services that support resource-based policies as described in User-Based and Resource-Based Permissions (such as Amazon S3, Amazon SNS, and Amazon SQS), an alternative to using roles is to attach a policy to the resource (bucket, topic, or queue) that you want to share. The resource-based policy can specify the AWS account that has permissions to access the resource.
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 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.