AWS知识点----身份验证

身份验证，简写为IAM，Identity and Access Management，是每一家做云计算的公司必须拥有的一个组件，没有它，什么计算、存储、网络都无从谈起。从用户的角度看，准备使用云计算时，第一步就是注册账号，然后在这个账号下创建资源，当然所有的资源都属于这个用户，所有云厂商也是使用这个账号来进行计费，所以 IAM模块非常重要。如果把学习云计算比成爬楼梯的话，熟悉IAM组件是要跨过去的首个台阶。

现在以一个新用户的身份来使用AWS，第一步就是创建一个用户，跟我们在其他平台注册流程差不多，提供手机号、邮箱，不一样的是还需要提供一个信用卡，用于付费。按照流程注册完成的用户称之为根用户，根用户拥有所有的权限，类似Linux操作系统的root用户，至高无上，是所有资源的主宰，其他的各种类型的用户都由它派生而来。

假设你所在的公司有一家合作伙伴需要在创建虚机资源，就是使用你刚才创建的账户，那该怎么办那？

可以肯定的是不能把根用户给他，那要么你帮合作伙伴创建好，当然这个过程费时费力还不讨好，要么就是创建一个IAM用户，并指定这个用户只能创建虚机资源，其他的操作都不允许，创建完成后把这个用户的账号密码发给合作伙伴，剩下的工作让合作伙伴去完成。当然后一个方法好，可节省你大量的时间，还不用承担责任。如果这个合作伙伴想使用编程来创建虚机，我们还可以给这个IAM用户创建访问秘钥，通过秘钥，可根据业务需求来动态的创建虚机。

过了几天，这个合作伙伴使用创建好的虚机部署了一套Web应用，该应用需要访问AWS S3存储服务，并且存储服务的属性为私有读写，需要提供秘钥才能访问。一般的做法是赋予该账户访问S3的权限，把该账户的访问秘钥写到程序里，这样就能实现这个功能，当然后期如果账户变更，所有的代码也要更改，较不灵活。

当有一个更高级的做法，叫做IAM角色。IAM角色类似于AWS用户，但它仅仅是一个身份，它可以确定具有这个身份的设备是否可以访问AWS的服务，并且这个身份一定要跟AWS的资源绑定。具体在这个场景中，只需要创建一个角色，它允许EC2访问S3，然后拉起虚机时将该角色赋予EC2，这样EC2中的应用就可以获得一个临时的安全凭证来访问S3，程序员不需要关心具体的实现过程。

下面看一个相关的问题：

Which of the following items are required to allow an application deployed on an EC2 instance to write data to a DynamoDB table? Assume no security key are allowed to be stored on the EC2 instance.

A: Create an IAM Role that allows write accesses to the DynamoDB table.

B: Add an IAM Role to a running EC2 instance.

C: Create an IAM User that allows write access to the DynamoDB table.

D: Add an IAM User to a running EC2 instance.

E: launch an EC2 instance with the IAM Role included in the launch configuration.

题目是说一个虚机里的应用程序如何才能写入数据到DynamoDB的表里，并且在虚机里不能存储安全秘钥。

首先从题干里就可以排除IAM用户，即使这个用户可以访问DynamoDB，但由于不允许在虚机里存储安全秘钥，创建IAM用户的方法就被排除了。

在虚机里增加用户的方法更不可取，因为虚机的用户和IAM的用户是两码事。

创建一个IAM角色，配置这个角色可以访问DynamoDB的权限，然后再把这个角色赋予虚机，这样虚机里的程序访问数据库的时候，AWS会自动生成一个临时秘钥给虚机里的程序，程序员不用关心。

通过上面分析，创建一个IAM角色是必须的，因此选项A没有异议，那么选项B和E，应该选哪个？向正在运行的虚机上增加角色是可以的，但前提是这个虚机不能有其它角色，否则就是替换角色操作，和选项E比较看，E是最佳的。

因此最终答案是A和E。