分享一下我们用代码来管理多个 AWS 账号的实践

另外 @Livid, AWS 区右边的链接似乎可以换成 https://github.com/boto/boto3 和 https://boto3.amazonaws.com/v1/documentation/api/latest/index.html

算了， 我还是老老实实的看 terrraform 吧

netflix 的 ConsoleMe 可以看一看. 他们全部基础设施都在 aws 上, 对 aws 的管理还是很有一套.

我们一般用 cdk 的

好奇这种双语的博客是要写两次么，还是写一份用软件翻译改吧改吧就行？

@wandehul @gtx990 这篇要点在于提供了多账号管理且不需要跨账号 assume role 的方式, 和是否使用 cdk/tf 没什么关系.

@Cabana 我是先用英文写的, 这两天放假有空全部人肉翻译了一遍再校对润色了一遍.

@joesonw 谢谢! 我们的全部基础设施也都在 aws 上. 看过 ConsoleMe, 不太喜欢这种自助式服务, 因为担心配置漂移, 另外我们还没有到那种需要为几百几千个人提供访问权限的程序.

膜拜大佬

在配置文件外面套一层 jsonnet 的话会更爽。

@xupefei 谢谢, 我们自己实现 jsonnet 那层逻辑也不算太大负担, 我现在只是有点后悔没用 toml.

你们是做 SAAS 的么，一个用户一个账号？

不太明白你们的应用场景。我就按一个最常用的场景来说。一些低权限用户可以提起创建账号请求，由高权限管理者批准，然后即可自动化创建。
既然你们要做某种 Infra as Code，那么权限应该在 Code 层面完成，也就是 Merge 代码之后鉴权就完成了，然后由一个 Infra 账号的管理 Role 去创建子账号，并在每个子账号内部创建一个 Admin Role，专为 Infra 账号 assume 用以便日后管理。

我不太理解为什么你们在完成 Infra as Code 的 Merge 之后还要在账户层面做权限管控，然后用一大堆流程来传输这种 Infra 代码并分布式（在每个账户中分别）执行。建议你们着重解释下这一点。

这种使用方法有些新奇

不是很明白这么做的好处。。

想问问为啥用 toml ？
eventbridge 跨账号传数据确实比 iam 风险高 需要额外的验证步骤

用户账号即代码？话说这个思路没问题，但是。。如果这个账号不用了如何搞？临时禁止了如果搞？代码一般是个无状态的东西，个人感觉 xxx 即代码比较难搞的就是这个状态。举个例子 terraform 在创建之后就会在本地或者远程保存一个状态文件。这样就不至于多人协同的时候搞乱了。

@whileFalse @akira 感谢两位的兴趣, 请允许我解释一下(看来我文章里面没有说清楚, 这一段回头也得加进去).

我们做这样设定的初衷是为了安全, 首先, 我们觉得 IAM User 不够安全, 所以我们设立了一个登录账号, 专门用来对接我们的 sso 服务. 用户 assume 了一个登录账号里的一个 IAM Role, 然后再 assume 另外一个 role, 去到他 /她真正要使用的账户.

然后, 我们做这些设定是认为总有一天我们的某一个账号会因为误用而导致被人拿到 Administrator 级的权限, 那么为了减少相关的影响, 我们不应该把所有的服务全部放到一个账号里面, 甚至也不应该把所有生产环境下的服务放到一个账号里去. 因为如果一个服务被人拿到权限, 那么所有的服务都会受影响, 因此, 多账号对于我们而言是必要的. 我上面写的这篇文章就是针对多个 AWS 账号的管理的一个方案, 这种方案各个公司多少都有, AWS 甚至还有 Control Tower 服务可以供使用, 但是我们觉得用 Eventbridge 来管理更适合我们.

如果你使用了多个 AWS 账号, 在费用上不会增加特别多, 真正增加的是你的管理成本, 尤其是几年之后你是否还能有效地管理这样的多账号环境, 每个账号里是否有配置漂移的情况, 我们觉得使用一个 DSL 并使用 CICD 来强制收敛是一个更好的选择.

@whileFalse 单独回答一下你的疑问. 我们不是做 SAAS, 在 AWS 层面, 也不是一个用户一个账号. 作为程序员, 张三和李四都可以通过两次 assume role 进入到要用的同一个账户里面去, 第二次 assume role 时使用的 Role 也是一样的. 方便讨论, 我们来一个假设的场景吧. 一个游戏公司里有多个工作室, 每个工作室有三个账号, 一个开发, 一个外部测试, 一个生产. 现在我们新开了一个工作室, 要加新 AWS 账号. 那么我们会要求主程去一个 repo 提一个 PR, 在一个 yml 文件里面添加新账号的定义. Infra 批了 PR 后进入自动化流程. 回头来看你的评论, 我不太确认你说的权限应该在 Code 层面完成是什么意思. 不过我认可你说的 merge 之后这个操作是被 Infra 同学认可了. 但是, 我们目前这个自动化流程是跑在专门的 cicd 账号里的, 不是 master, 所以没有办法直接创建 AWS 账号. 我们通过文章里提到的办法通过发消息来让 cicd 账号控制 master 账号, 创建新 AWS 账号. 至于这个账号里面的 Admin Role, 都是允许从那个特殊的`identity`账号来 assume role, 具体谁有权限是在那个账号管理的. 或者之前一篇文章里的一个图能够帮助你的理解: https://blog.xiaket.org/media/2020/okta-identity-destination.png

谢谢你们的提问, 让我意识到文章里面还有缺失的地方, 解释工作做得不够好, 我晚上改改.

棒棒哒，现在越来越多的公司碰到了 aws governance 的问题了

@vindurriel 因为 toml 是有可能进 stdlib 的, 而 PyYAML, 我看过源码, 有点一言难尽...

为什么你认为 eventbridge 跨账号传数据风险比 IAM 更高? 就我的理解, 一个账号是一个容器, 或者可以理解为一台服务器. 如果给了跨账号 assume-role, 类似于给用户提供了远程登录的接口, 而提供 eventbridge 的入口更像是通过 API 提供了服务. eventbridge 跨账号传数据应该是在 aws 的 control plane 层面传, 不走公网, 而且我们做了 resource policy, 不接受来自无关账号的消息.

@xderam 账号不用了就删掉呗, 这个月我已经干掉了 10 个账号了, 删完账号后配置文件里面再删掉就好, 目前来看, 不算太麻烦. 而且我们懒, 一般是该删的账号积了一堆后一次干掉多个, 节省时间和精力. 至于你说的那个状态, 我们是用 cicd 流程来保证配置和实际强一致收敛.

@xiaket 那就是还要手工删除账号？似乎也不是不可以。状态的那个解决方案似乎也没啥毛病。不过这么做的好处和弊端如果能再说说分享下就更好了。

@xiaket 原来是 pyyaml 那确实
assumeRole 这套是现成的 RBAC 上下游可以分别控制权限 用 eventbridge 不但得自己搞 发送账号还不好限制接收账号的权限（只能定义谁能看 不能定义看了能做啥）

@xderam 谢谢, 我们可以自动删账号的, 只不过目前我们觉得相对比较危险, 所以没这样做. 即, 技术上没有问题, 只不过我们没有去这样处理.

好处在于后面如果添加了什么新特性, 可以很方便地加到这个 DSL 里面, 可玩性可扩展性都比较好. 坏处嘛毕竟是自己写的, 有个后续维护的开销.

@vindurriel 谢谢, 大家对 pyyaml 看来是怨恨都很多. lol

我对 assume-role 的不满仍可以参见我上面的比方, assume-role 给了一台服务器的 shell 权限, 虽然是受限的; 而 eb 给了一个 api, 没有直接暴露 shell, 所以我们觉得放心一点. 不过对于 eventbridge 方案你提到的坏处我有点不太理解. 我为啥要限制接收账号的权限? 我定义好了消息的格式后就把命令丢出去, 这类似一个客户端请求, 受服务端处理的摆布在我理解算是正常的?

用法高端，如果是 PHP 的话我觉得已经传疯了