AWS攻略——一文看懂AWS IAM设计和使用

大纲

• 1 作用
• 2 初创公司IAM成长记
  • 2.1 根用户（Root User）
  • 2.2 用户（User）
    • 2.2.1 管理员
    • 2.2.2 普通用户
    • 2.2.3 规模膨胀
  • 2.3 用户组(User Group)
  • 2.4 角色（Role）
• 3 总结
  • 3.1 资源或服务（Resource Or Service）
  • 3.2 策略（Policy）
• 4 实操
  • 4.1 根用户（Root User）
  • 4.2 策略
    • 4.2.1 全权力（FullAccess）
      • 4.2.1.1 AWS托管的
      • 4.2.1.1 用户管理的
    • 4.2.2 限定权力
  • 4.3 用户（User）
    • 4.3.1 选择访问类型
    • 4.3.2 附加策略
  • 4.4 用户组（User Group）
    • 4.4.1 创建用户组
      • 4.4.1.1 起名
      • 4.4.1.2 附加策略
    • 4.4.2 创建附属于用户组的用户
  • 4.5 角色
    • 4.5.1 创建角色
    • 4.5.2 附加权限
    • 4.5.3 附加角色

1 作用

一言以蔽之，AWS IAM就是为了管理：谁 （不）可以 对什么 做什么。（转载请指明出于breaksoftware的csdn博客）

2 初创公司IAM成长记

2.1 根用户（Root User）

初创的软件研发公司“阿拉Software”，只有老王一人。他同时身兼老板和前后端研发工程师。为了管理方便，他只用了一个代码仓库管理了前后两端的代码。而作为根用户，他可以创建或删除代码仓库，但是不能提交代码，因为他还不是用户（User）。

2.2 用户（User）

2.2.1 管理员

老王为了能提交代码，他需要为自己创建一个用户（User）。由于只有他一个人，他就需要对代码仓库有全部权限。

2.2.2 普通用户

随着业务的快速发展，老王已经忙不过来了。于是他招聘了小李负责前端研发，小张负责后端研发。 小李经常会对整个工程进行字符串替换，偶尔会把后端的代码也改掉，造成线上Bug。为了规避这个问题，老王建立了前端代码仓库A，并只让小李提交；建立了后端代码仓库B，只让小张提交。

2.2.3 规模膨胀

在感受到代码功能分离带来的安全和稳定性后，老王要求每个独立的产品有各自的代码仓库。这样就不会因为A产品的代码改动，影响到可能同在一个代码仓库中的其他产品。 经过了半年研发，前端多出了C、E和G三个代码仓库；后端多出了D、F和H三个代码仓库。此时权限管理变成了这样：

公司的产品在市场上获得热烈的反响，老王准备扩大前后端研发团队以加速产品迭代速度。但是每次配置新人的权限时要非常小心，以避免配错或配漏代码仓库。

随着研发工程师数量的增多，老王之前一直未能尝试的产品也有了人力支持。于是老王要开启一个新项目，前端代码仓库是I，后端代码仓库是J。为了让他们都参与这个项目，老王需要对小李等6人权限所管理的资源进行修改。

2.3 用户组(User Group)

上述“规模膨胀” 带来了管理上的烦恼。老王要一直根据公司项目新增和人员增减做大量的权限调整，而且问题的规模随着人员数量的增长而递增。于是老王想到了使用“用户组”来管理员工的权限。

人员的增减带来的问题复杂度没有降低，但是项目增减带来的权限/资源调整则会规模性降低。 比如此时A和B代码仓库对应的项目已经非常稳定，不会再进行修改了。老王只要把前端组和后端组的权限做一次修改就行了，而不用挨个修改每个人的权限和资源。

2.4 角色（Role）

随着人员的增多，代码的质量把控越来越困难。老王此时想引入“线上自动化程序”来进行代码审查。不同于具体的人，“线上自动化程序”是一个抽象的概念。我们使用“角色”来对其进行管理和定义——它是一个代码审查角色。一个资源被赋予某个角色之后，它就会自动携带这个角色的权限，而不需要携带用于身份校验的秘钥对。

3 总结

对照IAM，我们将上述内容拆开看。即“对什么”对应于代码仓库——“资源或服务”；“做什么”对应于操作类型——“策略”。

3.1 资源或服务（Resource Or Service）

在本例中：代码仓库。

3.2 策略（Policy）

在本例中：创建和删除。

不管是角色（Role）、用户（User）还是用户组（User Group），它们都是通过策略（Policy）来表达的。换句话说，我们可以使用一个或者一组策略来描述角色、用户和用户组。于是，定义策略是使用IAM的基础。后续的实操将带大家进行一次IAM配置之旅。

4 实操

沿用上面的例子，我们对各个概念进行配置演示。

4.1 根用户（Root User）

根用户是我们注册AWS时的账户。该账户拥有所有的权力，所以用户名和密码需要保管好，以免泄露造成泄露。故事中老王是根用户的拥有者，但是他不能使用这个账户对AWS Codecommit进行代码提交。他需要在IAM中建立一个对AWS Codecommit拥有无上权力的用户。

4.2 策略

4.2.1 全权力（FullAccess）

我们在AWS IAM Policy页面可以看到策略。

4.2.1.1 AWS托管的

AWS IAM托管了大量其自己管理FullAccess策略，但是都是针对单个服务的。比如上图中圈中的部分。

4.2.1.1 用户管理的

我们可以自己创建同时拥有几个服务的FullAccess策略——Customer managed，比如同时拥有S3和EC2全权力的策略:

4.2.2 限定权力

以故事为例，假设我们在us-east-1区域创建了一个前端代码仓库A（名字是WebA）。那么我们希望前端同学可以对该代码仓库进行操作，但是不允许删除其上的分支，更不允许删除代码仓库。这可以进行下面的配置：

上述配置创建了一个名字叫“WebDenyCodecommitDeleteRespBranch”的用户自定义策略。它对资源使用了通配符*,用于表达该策略对对所有名字以“Web”开始的代码仓库都适用。这样老王后续新建的WebC、WebE等代码仓库都适用于这个策略。

4.3 用户（User）

我们可以在用户页面给小李创建一个用户。

4.3.1 选择访问类型

由于程序员可能会登录到AWS CodeCommit后台（类似于Github）看代码提交情况，我们就勾选下面那个Password选项。关于用户（User）更详细的使用方法，可以见之后的文章。

4.3.2 附加策略

在之前步骤中，我们创建了针对前端代码仓库进行管理的策略WebDenyCodecommitDeleteRespBranch。这一步我们就将该策略附加到用户上。这样XiaoLi这个用户就会被这个策略限制。

4.4 用户组（User Group）

用户组的创建和用户是类似的。我们先到用户组页面。

4.4.1 创建用户组

4.4.1.1 起名

以前端组为例，我们创建一个组叫做WebRD。

4.4.1.2 附加策略

和之前创建XiaoLi这个用户一样，让这个用户组附加策略WebDenyCodecommitDeleteRespBranch。

4.4.2 创建附属于用户组的用户

在用户（User）页面，创建小王对应的用户。 和创建XiaoLi这个用户不同的是，我们在第二步需要选择之前创建的用户组。

4.5 角色

阿拉Software公司的代码审查工具是部署在EC2（虚拟机）上，我们就需要在IAM中新建一个角色——CodeCheckRole。让这些EC2属于这些角色，进而拥有一些权限。

4.5.1 创建角色

4.5.2 附加权限

因为只是举例，没有对权限做严格的限制——直接附加了最大权力的FullAccess策略。

4.5.3 附加角色

在创建EC2实例时，我们在“IAM instance profile”中选择上述创建的角色。