Excellent Resource: http://www.infoq.com/cn/articles/aws-iam-dive-in

Users, Roles, Policies, Groups

Role

An IAM role is similar to a user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS.
However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it.
Also, a role does not have any credentials (password or access keys) associated with it. Instead, if a user is assigned to a role, access keys are created dynamically and provided to the user.
You can use roles to delegate access to users, applications, or services that don't normally have access to your AWS resources.

Access Management

Permission is just equivalent to policy
Identity-Based (IAM) Permissions and Resource-Based Permissions
http://docs.aws.amazon.com/IAM/latest/UserGuide/access_permissions.html

Types_of_Permissions.diagram.png

Managed Policies and Inline Policies

IAM和访问控制

Created based on : http://www.infoq.com/cn/articles/aws-iam-dive-in

基本概念

按照 AWS 的定义：

IAM enables you to control who can do what in your AWS account.

它提供了用户（users）管理、群组（groups）管理、角色（roles）管理和权限（permissions）管理等供AWS的客户来管理自己账号下面的资源。
1、首先说用户（users）。在AWS里，一个IAM user和unix下的一个用户几乎等价。你可以创建任意数量的用户，为其分配登录AWS management console所需要的密码，以及使用AWS CLI（或其他使用AWS SDK的应用）所需要的密钥。你可以赋予用户管理员的权限，使其能够任意操作AWS的所有服务，也可以依照Principle of least privilege，只授权合适的权限。下面是使用AWS CLI创建一个用户的示例：

saws> aws iam create-user --user-name tyrchen
{
    "User": {
        "CreateDate": "2015-11-03T23:05:05.353Z",
        "Arn": "arn:aws:iam:::user/tyrchen",
        "UserName": "tyrchen",
        "UserId": "AIDAISBVIGXYRRQLDDC3A",
        "Path": "/"
    }
}

saws> aws iam add-user-to-group --user-name --group-name
saws> aws iam create-login-profile --user-name --password
saws> aws iam create-access-key --user-name

2、群组（groups）也等同于常见的unix group。将一个用户添加到一个群组里，可以自动获得这个群组所具有的权限。在一家小的创业公司里，其AWS账号下可能会建立这些群组：
Admins：拥有全部资源的访问权限
Devs：拥有大部分资源的访问权限，但可能不具备一些关键性的权限，如创建用户
Ops：拥有部署的权限
Stakeholders：拥有只读权限，一般给manager查看信息之用

创建一个群组很简单：

saws> aws iam create-group --group-name stakeholders
{
    "Group": {
        "GroupName": "stakeholders",
        "GroupId": "AGPAIVGNNEGMEPLHXY6JU",
        "Arn": "arn:aws:iam:::group/stakeholders",
        "Path": "/",
        "CreateDate": "2015-11-03T23:15:47.021Z"
    }
}

然而，这样的群组没有任何权限，我们还需要为其添加policy：

saws> aws iam attach-group-policy --group-name --policy-arn

policy是描述权限的一段JSON文本，比如AdministratorAccess这个policy，其内容如下：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

用户或者群组只有添加了相关的policy，才会有相应的权限。

3、角色（roles）类似于用户，但没有任何访问凭证（密码或者密钥），它一般被赋予某个资源（包括用户），使其临时具备某些权限。比如说一个EC2实例需要访问DynamoDB，我们可以创建一个具有访问DynamoDB权限的角色，允许其被EC2 Service代入（AssumeRule），然后创建EC2的instance-profile使用这个角色。这样，这个EC2实例就可以访问DynamoDB了。当然，这样的权限控制也可以通过在EC2的文件系统里添加AWS配置文件设置某个用户的密钥（AccessKey）来获得，但使用角色更安全更灵活。角色的密钥是动态创建的，更新和失效都无须特别处理。想象一下如果你有成百上千个EC2实例，如果使用某个用户的密钥来访问AWS SDK，那么，只要某台机器的密钥泄漏，这个用户的密钥就不得不手动更新，进而手动更新所有机器的密钥。这是很多使用AWS多年的老手也会犯下的严重错误。

4、最后是权限（permissions）。AWS下的权限都通过policy document描述，就是上面我们给出的那个例子。policy是IAM的核心内容，我们稍后详细介绍。

使用 policy 做访问控制

上述内容你若理顺，IAM 就算入了门。但真要把握好IAM的精髓，需要深入了解policy，以及如何撰写policy。

前面我们看到，policy是用JSON来描述的，主要包含Statement，也就是这个policy拥有的权限的陈述，一言以蔽之，即：谁在什么条件下能对哪些资源的哪些操作进行处理。也就是所谓的撰写policy的PARCE原则：

Principal：谁
Action：哪些操作
Resource：哪些资源
Condition：什么条件
Effect：怎么处理（Allow/Deny）

我们看一个允许对S3进行只读操作的policy：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:Get*",
        "s3:List*"
      ],
      "Resource": "*"
    }
  ]
}

AWS IAM basic