问题描述
AK(AccessKey)是代表用户身份的钥匙，是用户访问阿里云API的身份认证密钥。如果部署在ECS实例中的应用程序需要访问各种阿里云服务API，用户通常会将AK保存在应用程序的配置文件中，使得应用程序能读取AK来调用阿里云服务API。这里存在两个问题：(1) 保密性问题。不管AK以何种形式存在于实例中，它都可能随着快照、镜像及镜像创建出来的实例被泄露。(2) 难运维性问题。由于AK存在于实例中，如果要更换AK（比如周期性轮转或切换用户身份），那么需要对每个实例和镜像进行更新并重新部署，这会极大增加对实例和镜像管理的复杂性。
针对保密性问题的通常解法是借助加解密(Crypto)或访问控制(Access Control)技术。
加密方案
由于AK本身也是一种密钥，而加解密技术通常不适合保护密钥本身，因为总有最后一把密钥(Last Key)是需要保护的，所以加密技术这里不适用。当然可能有少数区域的ECS实例提供了可信加密设备支持（比如HSM、TPM或SGX），但基于硬件来保护Last Key的方法是另一个专题，本文不做讨论。
访问控制方案
一种简单有效的AK保护做法是采用访问控制技术。比如，可以使用操作系统提供的访问控制机制来保护存放AK密钥的配置文件，比如
$ chmod 400 ~/.aliyuncli/credentials (只允许当前用户可读) 在用户登录管理严格的条件下，这种机制可以起到一定的保护作用。但由于AK本身没有加密，通过快照或镜像泄露之后就可能绕过访问控制机制，仍然可能泄漏。
针对难运维性问题就难解了，只要AK存在于实例文件中，对大量实例和镜像的管理复杂性就无法降低。
阿里云的技术方案
站在操作系统设计的角度，用户态中难解的问题，在内核态看来根本不是事。同样，ECS实例中难解的问题交给ECS管控来解，也不是难题。
阿里云ECS结合RAM (Resource Access Management)提供的访问控制能力，针对此问题提供了一个根本的解决方法 —— 通过给ECS实例配置RAM角色来避免AK泄露及运维难的问题。
技术原理
图1详细描述了如何给ECS实例配置RAM角色的工作原理：
(图1)
Step 1. 云账号(root)在RAM中创建一个ECS实例型的RAM-Role，并对角色授予合适的Policy权限。
Step 2. 启动ECS实例时，可以配置使用上一步骤中创建的RAM-Role。
以上两步的具体操作请参考通过控制台使用实例型RAM角色 或 通过API使用实例型RAM角色
所谓ECS实例型角色，它只是RAM服务角色中的一种类型，表示该角色是由客户创建并授权给该客户的ECS实例所使用。ECS服务在创建实例时：(i) 根据所配置的RAM角色，调用AssumeRole去访问STS请求获取该角色的StsToken；(ii) STS服务会验证ECS服务身份及该角色的授权类型，验证通过后颁发StsToken，否则拒绝请求。获取到StsToken后，ECS将通过Metadata服务提供给实例中的应用程序访问（HTTP访问地址：100.100.100.200 ）。StsToken过期时间通常为6小时，在过期之前ECS服务会自动维护StsToken的刷新。
Step 3. 获取StsToken。
ECS实例中的应用程序需要通过访问 ECS Metadata服务来获取相应的StsToken。比如， 在Linux中执行命令：
$ curl http://100.100.100.200/latest/meta-data/ram/security-credentials/<roleName> 即可获取StsToken及过期时间等元数据信息。
Step 4. 使用StsToken调用云服务API。
如果你的应用程序使用了阿里云SDK，那么阿里云SDK已经支持从ECS Metadata服务中获取实例RAM角色的StsToken，开发者无需在SDK中配置任何AK相关敏感信息。详细使用方法，请参考阿里云SDK支持InstanceProfileCredentialsProvider。
Step 5. StsToken在有效期内及权限范围内都能正常访问云服务API。如果StsToken过期，那么需要从ECS Metadata服务中重新获取StsToken；如果StsToken权限不足，那么需要找管理员给实例RAM角色添加足够的权限。实例RAM角色的权限更新后，StsToken权限立即生效，用户无需重新启动ECS实例。
关于RAM的PassRole说明
在上文的技术图解1中，读者可以发现授权者和ECS实例操作者都是管理员。而对很多企业客户来说，授权者和ECS实例操作者通常都是不同的RAM用户，不同的人干不同的事，职责分离。
那么针对管理员与操作员分离的客户场景，我们需要对图解1进行一下扩展，得到如下的图解2：
(图2)
除了增加Step 1.5之外，其它各步骤与图解1相同。
当RAM用户（假设仅有ECS权限，而并非RAM权限管理员）在创建ECS实例并配置RAM角色时，这个RAM用户必须要被授予对该角色的PassRole权限。ECS服务会强制检查当前用户是否拥有指定RAM-Role的 ram:PassRole 权限，否则无法成功创建ECS实例。这样做能确保只有被授权用户才能为ECS实例配置RAM角色，从而避免RAM角色权限被滥用。
Step 1.5 管理员给操作员增加一个PassRole权限。
管理员可以通过RAM按如下Policy样例创建一个自定义策略（注意替换rolename为自己的RAM角色名称），然后将这个自定义策略授权给操作员：
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": "ram:PassRole",
"Resource": "acs:ram:*:*:role/<rolename>"
}
]
}至此，你已经通晓了ECS实例型角色的概念和技术原理，赶紧开启安全最佳实践吧，让你不再因为ECS实例中的AK泄露和管理难的问题而烦恼了。
