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

Posted 2022-10-23 breaksoftware

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了AWS攻略——一文看懂AWS IAM设计和使用相关的知识，希望对你有一定的参考价值。

大纲

1 作用
2 初创公司IAM成长记
3 总结
- 3.1 资源或服务（Resource Or Service）
- 3.2 策略（Policy）
4 实操

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等代码仓库都适用于这个策略。