安全管理最佳实践系列：给ECS实例配置一个RAM角色身份（使用动态STS-Token访问云服务API）

问题描述

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泄露和管理难的问题而烦恼了。