大纲

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，只让小张提交。

谁	对什么	做什么
老王	对代码仓库A、B	做任何操作
小李	对代码仓库A	提交代码
小张	对代码仓库B	提交代码

2.2.3 规模膨胀

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

谁	对什么	做什么
老王	对代码仓库A、B、C、D、E、F、G和H	做任何操作
小李	对代码仓库A、C、E和G	提交代码
小张	对代码仓库B、D、F和H	提交代码

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

谁	对什么	做什么
老王	对代码仓库A、B、C、D、E、F、G和H	做任何操作
小李	对代码仓库A、C、E和G	提交代码
小王	对代码仓库A、C、E和G	提交代码
小赵	对代码仓库A、C、E和G	提交代码
小张	对代码仓库B、D、F和H	提交代码
小钱	对代码仓库B、D、F和H	提交代码
小周	对代码仓库B、D、F和H	提交代码

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

谁	对什么	做什么
老王	对代码仓库A、B、C、D、E、F、G、H、I和J	做任何操作
小李	对代码仓库A、C、E、G和I	提交代码
小王	对代码仓库A、C、E、G和I	提交代码
小赵	对代码仓库A、C、E、G和I	提交代码
小张	对代码仓库B、D、F、H和J	提交代码
小钱	对代码仓库B、D、F、H和J	提交代码
小周	对代码仓库B、D、F、H和J	提交代码

2.3 用户组(User Group)

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

谁	对什么	做什么
老王	对代码仓库A、B、C、D、E、F、G、H、I和J	做任何操作
前端组	对代码仓库A、C、E、G和I	提交代码
后端组	对代码仓库B、D、F、H和J	提交代码

组名	人员1	人员2	人员3
前端组	小李	小王	小赵
后端组	小张	小钱	小周

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

谁	对什么	做什么
老王	对代码仓库A、B、C、D、E、F、G、H、I和J	做任何操作
前端组	对代码仓库C、E、G和I	提交代码
后端组	对代码仓库D、F、H和J	提交代码

2.4 角色（Role）

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

谁	对什么	做什么
前端代码审查角色	对代码仓库C、E、G和I	进行审查
后端代码审查角色	对代码仓库D、F、H和J	进行审查

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”中选择上述创建的角色。

AWS攻略——一文看懂AWS IAM设计和使用相关推荐

一文看懂AWS IAM设计和使用
大纲 1 作用 2 初创公司IAM成长记 2.1 根用户(Root User) 2.2 用户(User) 2.2.1 管理员 2.2.2 普通用户 2.2.3 规模膨胀 2.3 用户组(User Gr ...
AWS攻略——VPC初识
大纲在网络里启动一台可以ssh上去的机器查看区域.VPC和子网创建EC2 连接 Web端连接客户端连接知识点参考资料 VPC是在AWS架构服务的基础,有点类似于我们在机房里拉网线和设置路由 ...
AWS攻略——使用CodeBuild进行自动化构建和部署Lambda（Python）
Aws Lambda是Amazon推出的"无服务架构"服务.我们只需要简单的上传代码,做些简单的配置,便可以使用.而且它是按运行时间收费,这对于低频访问的服务来说很划算.具体的介绍 ...
一文搞懂AWS EC2, IGW, RT, NAT, SG 基础篇下
B站实操视频更新跟着拉面学习AWS--EC2, IGW, RT, NAT, SG 简介长文多图预警,看结论可以直接拖到"总结"部分本文承接上一篇文章介绍以下 AWS 基础概念 ...
AWS攻略——使用CodeBuild进行自动化构建和部署静态网页
首先声明下,使用"CodeBuild"部署并不是"正统"的方案,因为AWS提供了"CodeDeploy".如果不希望引入太多基础设施,可以考 ...
AWS攻略——Peering连接VPC
文章目录创建IP/CIDR不覆盖的VPC 创建VPC 创建子网创建密钥对创建EC2 创建Peering 接受Peering邀请修改各个VPC的路由表修改美东us-east-1 pulic s ...
[转帖] 一文看懂：边缘计算究竟是什么？为何潜力无限？
一文看懂:"边缘计算"究竟是什么?为何潜力无限? 转载cnbeta 云计算雾计算边缘计算... 知名创投调研机构CB Insights撰文详述了边缘计算的发展和应用前景.文章称 ...
一文看懂前端和后端开发
作为一名开发者,你可能会想:2021 年最好的软件开发技术和编程语言会是什么?它们又是如何被应用在软件开发当中的?如果你在思考这个问题,那就来对地方了.这篇文章将对前端和后端开发技术做一个对比,先从基 ...
【燃】是时候展现真正的实力了！一文看懂2022华为开发者大赛技术亮点
摘要:2022华为开发者大赛备赛攻略,超详细的开发技术要点介绍来了. 本文分享自华为云社区<[燃]是时候展现真正的实力了!一文看懂2022华为开发者大赛技术亮点>,作者:华为云社区精选 . ...

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

大纲