使用 iamlive 获取最小权限

在亚马逊云科技，安全是我们的最高要务。安全被称作「第 0 件事」（Job Zero），意思是它的重要性比「头等大事」（Job No.1）更高一级。

为了满足安全方面的高要求，亚马逊云科技一直在推出安全相关的功能，并且对这些功能做细化。这也造成了一个双刃剑：

一方面，我们可以非常细腻地去创建、管理权限，达到安全合规的要求
另一方面，数百种服务，成千上万的 API，不同的资源和限制条件，又让人望而生畏

在这篇文章里，我们介绍一款由亚马逊云科技社区英雄（AWS Community Hero，指对 AWS 社区生态做出卓越贡献的开发者） Ian McKey 开发的开源软件，看看它如何帮助我们来更好地熟悉和配置 Amazon IAM（Identity and Access Management）权限。

IAM 简介

早在本世纪初，亚马逊就强调过 API 的重要性，并且要求部门之间的数据传递和业务行为，不能通过邮件、口头沟通、传输文件等方式，而是必须通过 API 来完成。这意味着所有的业务行为和数据交换都被数字化，可以提高效率，避免人为错误，并且让所有的行为都可以被很好的追溯和审计。

进入云时代，亚马逊云科技也继承了这一理念。基本上所有我们在 Web 界面、命令行能够执行的操作，都有对应的 API，而我们也可以对这个 API 进行访问控制，并且记录每次调用的上下文。

在亚马逊云科技，对 API 管控的机制被称作 IAM，即身份和权限管理，正好也谐音「I am（我是…）」，很容易记忆。

IAM 的核心是权限策略（Policy）。策略包含如下 4 个核心元素：

主体（Principal），即这条策略针对「谁」生效
动作（Action），即这条策略针对的具体 API
资源（Resource），即这条策略针对的具体亚马逊云科技资源
条件（Condition），即这条策略生效的前提条件

策略的性质可以是「允许」（Allow）或者「拒绝」（Deny）。

一个问题

现在，假设我是一个亚马逊云科技的客户，我主要负责运维和安全。我希望给我的 AI 团队一些账号，这些账号可以在 Amazon SageMaker 上开启笔记本，从 S3 上下载数据，然后做一些探索。

我该如何设置权限？

在翻阅 API 文档之后，我看到了 sagemaker:CreateNotebookInstance 和 sagemaker:StartNotebookInstance 权限。字面上看，一个是「创建实例」，一个是「启动实例」，所以，我给了用户这两个权限。

在控制台上操作之后，发现出错了。用户要使用 SageMaker，还需要为它创建一个角色用于从笔记本内访问 S3，而我并没有给用户创建角色的权限。查看文档之后，我看到了 iam:CreateRole 权限，还有 iam:CreatePolicy 权限。

添加上之后，发现还是不行，仔细一看错误信息，原来是少了一个 iam:AttachPolicyToRole 权限。

在添加权限之后，又发现另一个问题：无法把这个角色关联到实例。在文档的深处，我们发现原来要给某个资源赋予角色，必须要有 iam:PassRole 权限。

经过一番折腾之后，我们终于可以启动笔记本实例。而此时，我们整个任务才完成了一半，因为我们只给了 iam:CreatePolicy 权限，却没有设置边界，所以理论上用户可以创建一条包含 *:* 的权限，附在角色上，从而在 SageMaker 笔记本内获得管理员权限。

这是一个反复尝试并且排错的过程，耗时费力。因为它很耗时费力，很多时候用户可能会「临时」使用一个很宽的权限，比如 SageMakerFullAccess 或者 S3FullAccess，从而造成很大的安全问题。

如果有一个工具，可以帮助我们快速了解做到一件事所需要的所有权限，那就会大大减轻安全人员的负担，从而让大家更愿意去细粒度地设置好最小权限，保障系统安全。

今天我们介绍的 iamlive 就是这样一款工具。

iamlive 原理

这里简述一下 iamlive 的原理，如果对原理不感兴趣的读者，可以直接读下一节的使用指南。

iamlive 有两个模式，一个是默认的「客户端指标模式」（Client-Side Metrics，下简称 CSM），另一个是「代理模式」（Proxy Mode）。

CSM 是 AWS SDK 推出的一项功能，可以在 AWS SDK 调用 API 时向指定地址发送调用信息，以便开发者对服务调用做统计、识别异常调用等，这个功能也可以在 AWS CLI 上开启，从而让我们可以在 AWS CLI 调用 API 时也获得具体的调用信息。而代理模式则是使用了 AWS CLI 的 SSL 代理功能，通过自建 SSL 中间人服务器来捕获调用信息。

iamlive 使用

安装

我们可以到 iamlive 的 GitHub 发布页面下载对应的预编译应用，解压即可。针对 macOS、Linux 和 Windows 都有预编译的版本。

Linux 的用户可以安装 Go 之后自行克隆仓库并使用 go install 编译安装。而 macOS 的用户也可以使用 HomeBrew 工具，执行 brew install iann0036/iamlive/iamlive 进行安装。

当然，它也有 Lambda Extension 以及 Docker 的版本，方便我们捕获 Lambda 的调用和在 Docker 内部捕获调用。这些可以在 GitHub 仓库页面找到。

AWS CLI 的 CSM 模式

iamlive 的使用非常简单。下面，我们先以 AWS CLI 为例。

使用 CLI 时，我们只需要执行如下命令：

iamlive --set-ini --profile myprofile

其中 --set-ini 意味着在 iamlive 启动时，会自动为你的 ~/.aws/config 文件加上 csm_enabled = true，退出时再删除这个配置，避免影响效率或者造成 API 调用记录外泄。而 --profile myprofile 则意味着我们只针对这个 Profile 添加这条配置，这里请把 myprofile 换成你的 AWS CLI Profile 名字。如果本身没有为 AWS CLI 创建 Profile，则可以省去。

运行命令后，iamlive 进入等待状态，此时，我们可以再开一个窗口，使用 AWS CLI 执行命令。

通过观察我们发现，aws sagemaker create-notebook-instance 有如下几个必选参数：

其中 --role-arn 意味着我们需要提供一个 IAM 角色。所以，我们可以先执行创建 IAM 角色的命令。

先创建 assume-role-doc.json 文件。

cd /tmp
cat <<EOF> assume-role-doc.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "sagemaker.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}
EOF

这意味着我们创建的角色只有 SageMaker 可以使用。然后，执行 AWS CLI 命令。

aws iam create-role --role-name test-sagemaker --assume-role-policy-document file://assume-role-doc.json

执行成功后，我们应该可以在 iamlive 的窗口看到权限已经出来了。

此时新创建的角色还是空的，所以我们再给它创建一个策略。注意：把 BUCKET_NAME 和 FILE_NAME 换成你自己的 S3 桶中的某个文件，我们稍后用这个文件来做简单的权限测试。

cat <<EOF> s3-policy.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::BUCKET_NAME/FILE_NAME"
        }
    ]
}
EOF
aws iam create-policy --policy-name test-s3 --policy-document file://s3-policy.json

记录下输出的角色 ARN。接下来，我们把这个权限附着到角色上。注意：把 ACCOUNT_ID 改为你自己的账户 ID，账户 ID 为 12 位数字。

aws iam attach-role-policy --role-name test-sagemaker --policy-arn arn:aws:iam::ACCOUNT_ID:policy/test-s3

然后我们可以创建新的 SageMaker 实例。注意：同上，此处 ACCOUNT_ID 也需要改为自己的账户 ID。

aws sagemaker create-notebook-instance --notebook-instance-name test-iam --instance-type ml.t2.medium --role-arn arn:aws:iam::ACCOUNT_ID:role/test-sagemaker

再回到 iamlive 界面，我们可以看到它已经捕获了目前所需的权限。

AWS SDK 的 CSM 模式

看上面的权限，你可能会有疑惑。既然大部分的 API 都有直接对应的权限，那么，直接把这些 API 对应的权限都加上，不就可以了吗，为什么还需要 iamlive 来捕获？

确实，除了少部分情况，以及像 iam:PassRole 这样的隐藏 API，大部分的权限都和 API 直接对应，所以在使用 AWS CLI 时，iamlive 能提供的更多是学习和辅助。它更大的作用，是用于梳理应用程序实际上用到的权限，并进行限制。

当我们运行的后台应用通过 AWS SDK 调用 API 时，我们也可以通过 iamlive 捕获。在应用运行一段时间后，我们就能获得这个应用使用过的所有 API，从而将它的权限限制在这些 API 上。结合自动化测试，我们可以在应用迭代时，也对权限进行迭代。

启用 AWS SDK 的 CSM 模式也很容易，只需要加入如下环境变量，再运行即可。此处默认使用 iamlive 的本地监听，端口为 31000。

export AWS_CSM_ENABLED=true
export AWS_CSM_PORT=31000
export AWS_CSM_HOST=127.0.0.1

使用 AWS SDK，我们只需在新窗口运行 iamlive，不需要添加参数。iamlive 会默认监听 31000 端口，捕获输出。

此处以 AWS 的 Python 版 SDK，即 boto3 来举例。在加入了环境变量的终端窗口，我们可以创建一个 Python 文件并且执行它。

cat <<EOF> test.py
import boto3
client = boto3.client('s3')
client.list_buckets()
EOF

python test.py

然后，在 iamlive 窗口就可以看到对应的权限已经被捕获。

在代码构建和自动化测试的过程中，我们可以使用 CSM 模式，捕获该应用所使用的实际权限，并且实时对权限进行更新，可以做到权限最小化，并且权限追随应用版本迭代，达到较好的安全性。

代理模式

如果使用「CSM 模式」，那么我们是没办法获取 Resource 信息的，因为这个模式主要是用来做一些指标监控，而不是记录详细的调用日志。如果要获取 Resource，则我们需要切换至「代理模式」。

使用代理模式时，iamlive 会在本地起一个代理服务器，并且使用自签名的证书，截获 API 调用，然后再做转发。因为截获了完整的调用，所以就可以看到 Resource 了。

需要注意的是，这里的 Resource 仅供参考，实际应该怎么配置，安全人员应该自己做好判断。此外，代理模式比客户端监控模式稍复杂，如果没有强需求，还是可以使用 CSM 模式，并且自己判断如何来写 Resource。

具体的代理模式操作，可以参考 iamlive 的 GitHub 页面，限于篇幅，本文不作赘述。

总结

本文介绍了如何使用 iamlive 来方便地获取最小用户权限。工具虽好，在使用时，还请注意以下问题：

虽然这个开源工具是亚马逊云科技社区开发者所写，但并不是官方的工具，用户需要自行判断是否能承担开源软件所带来的风险
因为这个工具只是用来获取 IAM 权限，所以用户应该只在完全隔离的账号环境中使用，获得并记录最小权限后，即删除测试账号、用户以及工具资源
在 Web 控制台上，很多操作属于「综合调用」，即把多个 API 调用放到了一个步骤（比如创建策略、创建角色、创建实例），用户必须要能把控制台上的操作拆解成实际 API 调用再使用 iamlive 来获取对应权限
使用 AWS SDK 的 CSM 模式，将权限也纳入自动化测试，可以做到权限和应用版本一起迭代，提升安全性
这个工具无法确保权限边界的问题，这需要安全人员在设置权限时，做好对应规划和对应配置
为了避免权限设置失误的情况，用户还应该设立 API 调用异常的事中告警和事后审核机制

安全无小事。在后续的文章中，我们再来介绍针对一些常见场景的 IAM 策略写法。

亚马逊AWS官方博客