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.
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. 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 Amazon S3, Amazon Glacier, Amazon SNS, Amazon SQS, and AWS Key Management Service. For a list of which services support resource-level permissions, see AWS Services That Support IAM.
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.
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.
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.
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 (Delegation and Federation).
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.
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.