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
- 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::<ACCOUNT-ID>: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::<ACCOUNT-ID>: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": "*"
}
]
}
