前言
使用 AWS 可以帮助我们快速构建需要的环境，在构建 demo 的过程中可以随心所欲玩耍。但在实际使用过程中，则必须要考虑用户授权，应用以及各种资源的安全性问题。关于这类安全，在 AWS 中都由一个叫 IAM 的服务进行管理
什么是 AWS IAM ？
IAM (Identity & access management) 服务能否让我们以可伸缩的方式，安全的管理标识、资源的权限
对于运行在AWS上的应用程序，我们也可以使用细粒度的访问控制来授权员工、应用程序和设备访问AWS服务和资源
说简单一点就好比下面这张图
- 用户具有某个角色
- 某个角色具有某些权限
- 该用户就可以做在这些权限被允许的操作
这只是简单的理解，其实 IAM 的控制关系并不是这样，另外 IAM 控制的力度以及可控的范围要远远比上面的图精细，因为其控制精细，所以在使用 IAM 服务时的基本准则是：
授予最小权限
走进 IAM
AWS 的服务多是都是按照区域划分，但 IAM 是为数不多的几个 Global 服务
IAM 组成
IAM 的组成还是很简单的，只有下面这几部分组成
接下来我们就可以创建相应的部分来进一步理解 IAM
创建 Group
创建 groups 的步骤很简单，只需要简单的三步，这里命名为 「aws-learning」
点击下一步，接下来需要添加 policy（policy 就是指具体的操作权限），这里默认展示的都是 AWS managed 的policy，这里暂时选择 AdministratorAccess (这是不可取的方式，违背最小权限准则，仅仅作为展示)，这些是 AWS 默认提供的 policy，如果默认选项不满足要求，当然也可以创建我们自己的 policy
点击下一步，做一个基本的 review 一览就可以创建我们的 group 了，创建成功后就是这个样子
这个 AdministratorAccess 的权限有多大呢？ 点开 Show Policy 就可以看到了，其实 Policy 就是一种 JSON 形式数据：
<img src="https://cdn.jsdelivr.net/gh/FraserYu/img-host/blog-img20200822182458.png" style="zoom:50%;" />
上面的 JSON 语义很好解释
允许 (Allow) 对所有资源 (Resource ) 做所有操作 (Action )
所以当我们自定义 Policy 时，也是要采用这种 JSON 格式
定义 group 就是方便我们以组的形式来管理用户 user，当然一个 user 也可以属于多个 group。接下来我们就可以创建 user 将其放到我们刚刚创建的组内
创建 User
创建 user 也很简单，只不过在创建的时候选择该账号具有的权限即可，就像下面这样：
点击下一步，就可以选择将该 user 添加到某个 group 中，或者为这个单独 attach 一个 policy
创建完成后，就像下图显示的这样：
创建 Role
点击 Create Role 按钮，进入如下界面：
选择相应的 AWS Managed Role ， 这里选择 EC2 ，进入下一步，
点击 Finish 按钮后，当前的 Role 就 attach 了操作 EC2 的policy。
创建好的 Role ，也可以通过在 TrustRelationship 的位置为某个 AWS Service assume 这个 role，被 trust 的 service 也就具备了这个 role 相应的 policy, 就像下面这样：
创建 Policy
创建 Policy 没有什么特殊的。Policy 就是一个用户或者 Role 具有的权限，除了 AWS managed 的，我们也可以自定义，如果你不理解相应的语法关键字，AWS 还贴心的提供了 Policy 模拟器，可以让我们通过鼠标点击选择的形式，生成 Policy，然后将其转换成 JSON 格式的数据
这里有朋友可能会有疑问了：
User/Group attach policy，Role 又同样 attach policy，那它俩到底啥区别呢？
User 和 Role 的区别
刚接触 AWS 你可能会在上面的这个问题上有一些困惑，二者都可以 attach policy ，所以主要说一下什么时候需要创建 User，而什么时候有需要创建 Role
什么时候需要创建 User？
-
你自己创建的 AWS account，并且这个账户中只有你，那么你只需要创建相应的 User（注意这里最好不要使用 root user），并 attach 相应的 policy 即可
- 假如还有其他人需要在你的 AWS account 下工作，但是没有其他的 identify 机制，这时也可以创建 User，并使用相应的 group 进行管理即可
所以总结来说，当 AWS account 仅有少许个人，并且没有什么 identify 机制会选择创建 User 的方式，很显然这种不是企业级选择方式
什么时候需要创建 Role？
-
假如你有一个应用运行在 Amazon Elastic Compute Cloud (Amazon EC2) 实例上，并且这个应用需要请求其他 AWS 服务 （因为要请求其他 AWS service，通常需要合法的用户名和密码，如果将这些敏感信息暴露在程序内，显然不符合 AWS 的管理思想；相反，使用 Role 的方式，会使用临时生成的 credentials 访问 AWS 服务，这种更加安全）
-
你有个移动端的应用，需要访问 AWS 服务 （做过移动端的朋友可能会知道，这种需要类似 OAuth 2.0 的方式，AWS 也是这样的方式。可以通过创建 identify provider，比如 Amazon，Cognito，Facebook, Google 等的用户授权，将其匹配到某个 Role 上，再通过临时的 credentials 访问 AWS 服务）
- 当公司使用 AWS 服务，创建的是 federation 类型 Account，此时希望不通过 login 的方式使用 AWS 服务
所以说，一般企业级应用都会采用 IAM Role 的方式进行认证授权，这一切的前提就是需要 创建 IAM Identify Providers
这个由于涉及到一些保密配置，这里不再展开说明，按照官网文档进行配置即可，非常简单，整个实现原理如下图显示
总结
AWS IAM 是 Global 的服务，也是 AWS 保证资源以及应用服务安全的重要服务，如果个人实验 AWS，只需要创建 User，attach 响应 policy 即可，如果企业级应用，通常都会结合 Identity Provider，以 IAM Role attach policy 的形式进行验证授权，到目前我们都是通过在 AWS Console 上创建相应的组建，实际工作中都会通过 CloudFormation 的定义来创建相应的服务