IAM是什么?

本文旨在给刚准备上手/稀里糊涂上手AWS的小伙伴们非常简单地普及一下AWS 的IAM文章，希望大家能在项目中逐渐深入地理解这些概念，AWS文章应该会做成一个系列。

IAM是什么？

AWS Identity and Access Management (IAM), 这是AWS的一个服务，帮助用户安全地对AWS资源进行控制,这么说可能有点难懂，让我们来看下AWS下的四个概念吧

image-20210124222401226

用户（User）：代表访问AWS的终端用户
可使用密码来访问AWS管理平台
可使用Access Key ID和Secret Access Key并通过API, CLI或SDK的形式来访问AWS服务
默认用户没有任何权限，我们需要用策略赋予每个用户所需要的最小权限
组（Group）：拥有相同权限的用户组合
拥有相同权限的用户可以归入一个组，方便权限的统一管理和控制
一个组可以拥有多个用户，一个用户可以属于多个组
角色（Role）：角色可以分配给AWS服务，让AWS服务有访问其他AWS资源的权限
- 角色不包含任何用户名/密码
- 角色比用户更加安全可靠，因为没有泄露用户名/密码或者Access Key的可能性
- 举个例子，我们可以赋予EC2实例一个角色，让其有访问S3的读写权限
策略（Policy）：定义具体访问权限的文档
策略具体定义了能访问哪些AWS资源，并且能执行哪些操作（比如List, Read, Write等）
策略的文档可以JSON的格式展现

根用户（Root User）

根用户：在我们创建账户第一次登陆的时候，其实登陆的是根用户，而AWS并不推荐使用根用户来执行日常任务,而应当使用被赋予了AdministratorAccess的用户来管理日常任务（包括之后的为 AWS 账户设置其他组、用户），使得这些用户成为管理员。

通过为访问账户的人员创建单独的 IAM 用户，可以向每个 IAM 用户提供一组独特的安全凭证。我们还可向每个 IAM 用户授予不同的权限。如有必要，我们可以随时更改或撤销 IAM 用户的权限。(如果公布了根用户凭证，则很难将其撤销，且不可能限制它们的权限。)

image-20210124222446487

用户(User)

在我们还提到了Access Key ID和Secret Access Key,这两个其实是当我们操作cli或者编写代码的时候使用的,在我们创建成功用户的时候便会给我们包含User name 、Password 、Access key ID、 Secret access key的 .csv文件

截屏2021-01-24 下午10.54.44

截屏2021-01-24 下午10.56.24

创建完成后，可以看到用户可以被加到不同的组里了，这是在创建用户的时候便可以设置的(这里我们没有截图出来这个步骤，大家可以自行去试一下)

image-20210124222509817

在针对组的操作之前，我们还可以对用户附加单独的策略，如下图所示，直接附加的策略是我们单独给这个hao.gu2的用户加的，而从组内附加的策略，我们可以去组内管理。

image-20210124222525168

组(Group)

在组中，我们可以设置这个组内所有成员的AWS资源权限，比如下图，我们可以大概从名字看出来，prod这个组拥有RDS、EC2全部的访问权限，只有DynamoDB的read权限。

image-20210124222605568

通过这种方式，我们就不用再每次创建一个新用户的时候，耗时耗力地去给他添加策略了，只需要把他加到现有的组中，就可以完成这个用户基本的权限控制，当这个用户还需要额外的权限时，我们也可以单独地附加给他。

策略(Policy)

那么这个策略是什么呢？AWS已经给我们准备了各种各样的通用策略，下图是AWS已有的s3策略，一般情况下这些策略都是对所有的s3起效果，那么如果我们只想让用户访问一个特定的s3资源呢该怎么做呢？

image-20210124222632428

AWS提供给我们可视化的编辑器来编辑我们的策略，如下图，我们可以选择相对应的服务,，然后选择我们赋予所需的权限操作，还可以指定这些操作哪个特定的S3，这些选项最后都会转成Json格式保存起来。用户只会获得所有分配

image-20210124222656783

image-20210124222715673

关于Policy的逻辑可以设计的非常多样化，但是仍然可以总结成一句话，只有具备显式的 Allow，并且没有显式的 Deny，才有权限。

举个例子：

如果同样的资源既有Deny，又有Allow，那么最终会是Deny.

如果有一个资源没有被Allow，那么就会被Deny

角色(Role)

终于轮到介绍角色了：

这是一个很容易与”用户”混淆的的概念，IAM 角色非常类似于用户，它具有确定其在 AWS 中可执行和不可执行的操作的权限策略。但是，角色没有任何关联的凭证（密码或访问密钥）。角色旨在让需要它的任何人代入，而不是唯一地与某个人员关联。IAM 用户可担任角色来暂时获得针对特定任务的不同权限。

看起来似乎“用户”也能很好的完成这些任务，那么为什么还需要”角色”这个概念呢？

我们来看一看”角色”这一概念的应用场景:

AWS服务角色（例如：EC2，Lambda，Redshift等）

我们的用户的策略是针对用户的账号而言的，我们可以限制登录这个账号的人能去做什么，不能做什么，那么怎么控制某个AWS的服务他的功能呢？

这个时候”角色”就出场了，比如我们可以创建一个EC2的角色，并赋予他一些Policy，使其只能访问S3(如果没有赋予角色，默认是不能访问其他的AWS资源的)，这样我们就能做到控制AWS服务的功能，

在上面这个例子中明显是不适合用户的场景，EC2只是我们的服务，他不应当有用户这个概念，但是我们需要做的事情又跟”用户”很像，都是去控制他所能做的事，那么就有了角色这个概念。

image-20210124222805157

image
- 实施最小权限原则
  
  这指的是仅限特定任务需要时，才能使用提升的权限。借助角色，我们可以帮助防止对敏感环境进行意外更改，
  
  举个栗子：
  
  假如有这么一个EC2实例，上面跑着公司最核心的业务代码，我们可以创建具有停止权限的角色，而不是直接向用户授予终止实例的权限。
  
  当我们想终止这个EC2时，我们需要切换角色，才能执行终止操作。
  - 跨账户访问：从其他AWS账户向用户授予权限，无论我们是否控制这些账户。
    
    我们可以向 IAM 用户授予权限，以便切换至我们自己活着我们拥有的其他 AWS 账户中定义的角色。
    
    这个场景非常常见，比如某个组织通过多个AWS账号将开发环境和生产环境隔离，开发账户中的用户有时可能需要访问生产账户中的资源。
    
    当然我们可以在两个账户中工作的用户创建单独的身份 (和密码)，但是这种情况下我们还需要管理多个账户的凭证，带来一些困扰。
    
    这个时候就可以通过角色来方便地管理这一点啦。
    
    举个例子：
    1. 在Prod账号(123123123123)中创建一个UpdateAPP的角色使其能对Prod账号下的S3读取和写入，并且定义信任策略，将Dev账号指定为Principal。
    1. 在Dev账号(456456456456)中授予用户切换为角色的权限。这样我们就可以在Dev账号中切换成Prod账号的角色，来操作Prod账号下的AWS资源了。
```
如下图所示，先在Prod账号(123123123123)中创建一个给Dev账号(456456456456)用的角色，并且赋予该角色访问S3的权限，最后到Dev账号(456456456456)中赋予用户切换角色的权限(此处省略)，然后切换角色，输入Prod账号(123123123123)和角色名即可切换了,通过这种方式，我们不用登出自己的账号便可访问其他账号下的资源。
```
    image-20210124222850028
    
    image-20210124222906613
    
    image-20210124222931407
    
    好啦，以上就是IAM最主要的四个概念的简单介绍，希望大家不要像我一样过了SAA结果这些概念还是稀里糊涂，考试就只顾着刷题去了。略过了不少子概念是因为想把这篇文章变得简单易理解，而不是像用户手册一样，而用户手册AWS已经有了。如下链接
    
    https://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/access_policies_managed-vs-inline.html
    
    TODO:
    
    AWS Cli整合IAM
    
    AWS Organization