自动化场景-多账号自动化场景下的AK管理方案

以下是视频转写全文，供参考：

欢迎回到阿里云开放平台自动化专栏AutoTalk，我是开放平台解决方案架构师遥方。本期我给大家带来的分享主题是多账号自动化场景下的身份管理方案。

不知道大家有没有尝试用这个代码的方式来操作阿里云的这个资源。如果我们要写程序，或者通过Terraform等工具进行一些自动化，我把它抽象成大概有三步。首先，您需要有一个程序的身份，就是您必须要有一个AK来操作阿里云API，这就是第一步。然后第二步，您一定要有一个账号，因为所有的资源都在一个账号里面。第三步，您需要调用阿里云的API，去创建像ECS、OSS这些资源。

那我们讲这个程序的身份，就是我们的应用程序去调用我们的API。这个身份的认证，阿里云提供两种方式，一种是我们有一个固定的凭据，我们叫AccessKey，简称AK；还有一种方式是我们用一些临时凭据的方式，我们叫做STS的Token。在程序使用这个AK也好，还是用STS Token的方式也好，我们也看到很多常见的风险。比如说有些客户可能用这个主账号来操作我们的API，而主账号的AK的风险是很高的。

因为它一旦被泄露，您要去止损的话，这个成本是非常高的。或者说有些用户可能会把这个AK直接硬编码到我们的代码里面，一旦这个AK泄露，可能对我们的账号的风险影响非常大了。

基于这样的风险，我们其实是有一些最佳原则在里面的，总结起来其实就是两点。第一个是尽量缩短暴露的时长。怎么来理解呢，比如说我们可以用固定的凭据AK，而固定的凭据可能会存在很长的有效期，只要不去轮转它，这个AK可能会被研发人员使用了一年、两年甚至十年对吧？这个AK一直在，这个时长是非常长的。但如果我们可以通过一些策略，比如定期进行轮转，比如说每半年进行一次轮转，那么这个AK的有效期就可以控制在一定范围内，或者我们可以用一些临时的Token，这是一种方式。

第二种方式是尽量缩小暴露的面积，比如说在测试环境和生产环境中，我们可以使用不同的凭据，而不是用一把凭据操作所有环境，甚至有些人可能会用一个AK操作他们所有的应用，大家可以想象一下，如果这个AK一旦被泄露，所有的系统都会受到影响，这是一个比较简单的理解，刚刚我们提到的临时的Token，实际上在云上也有一些最佳实践。比如，如果我们使用ECS，将程序部署在ECS上，ECS提供了一种方案，称为实例角色功能，大家可以理解为我给这个ECS实例分配一个角色，然后它就可以操作云上的一些资源。这样一来，我的程序就不会感知到AK的存在的。只要把代码部署在这台ECS上面，我就有相应的权限。因此，大家可以想象，这里面肯定不会存在AK泄露的问题，因为程序根本无法感知AK的存在，所有凭据都是在这台ECS实例上。这是一种实践。我们有很多客户，他们的用户其实是多账号的。我不知道大家是否理解，或者是否使用过我们的多账号的管理产品，我们的资源目录其实是个账号树，大家可以简单看一下，比如说我们有很多业务，业务A、业务B，每个业务可能都有一个账号，A1、B1、C1等。如果今天我们要进行一些自动化的操作，可能会开一个新的云账号，比如说运维账号C。在运维账号C中运行我们的脚本，或者是我们的流水线。比如，我们搭建了一个Jenkins，或者使用阿里云的云效。在运行流水线的时候，肯定需要操作业务A1和B1账号中的资源，也就是说需要这两个账号的身份和权限。如果A1账号给你一个AK，B1账号给你个AK，大家可以想象一下，AK泄露的风险是很高的。而且每个账号都要开一个AK，这对管理效率、管理成本也是很高的。

所以我们其实如果说我们的这个，就是你刚好看到了这样的一个图，并且你们的企业正好也是这样的一个多账号的场景。那我强烈建议你们可以用这套方案，我简单讲一下，就是说我们可以在这个运维账号里面，刚才讲的这个ECS实例，比如说我们开一个ECS实例，然后这个实例的话，我们可以给它一个实例角色。这个实例角色其实是有扮演的功能的，它可以扮演我们的这个管理账号，这个叫做我们的所谓的根账号里面的一个角色。那这个角色的话，它有权限去到每一个账号里面去做这些资源的开通管理的操作的。我们其实在整个的这个过程里面，是没有一个明文AK的，这个是我们这个方案里面非常重要的一点。

其实就是核心用了两个能力，一个是这个资源管理树，就是有一个资源目录这么一个树，能够管理这些成员账号。另外一个很重要的点是，我们在运维账号C里面，要扮演一个角色，这是这个方案了。

接下来的话，我们有一个演示，这张图我大概给大家介绍一下，这是一个非常典型的多账号的架构。一个企业有很多账号，刚刚讲到的运维账号需要做一些自动化的程序，而这个程序大概率就是部署在运维账号里面。然后它有生产账号A、B以及其他很多的账号，所有的自动化程序可能都是跑在运维账号C里面的。接下来我们来看一下大概是有几步。

首先，我们在运维账号中创建一个ECS角色ecs-role，它的权限包括STS的AssumeRole权限，这是我们给这个角色授权的内容。然后我们的ECS就可以关联到这个实例角色上，即在这台自动化程序的ECS上关联到这个角色。第二步，我们在管理账号中创建一个角色，例如automation-assume。这个角色的权限包括资源目录的权限和STS AssumeRole的权限。接着，在运维账号中配置ECS的角色，并且在这台ECS上安装阿里云的CLI的工具，这样就可以拿到我们的临时AK了。

好的，那接下来我会给大家做一个简单的实操。这个是我们的演示的环境，这是我们的多账号的树，我现在登录这个账号是我们的资源管理的主账号。完成之后，我们会选择一个运维账号，这个账号将用于运行自动化的程序。我这边也简单写了几个操作步骤，我们可以简单看一下。首先，我们会在这个运维账号中创建一个可信实体类型为阿里云服务的角色ecs-role，并为这个角色创建一个调用STS服务的权限。

然后第二步，我们会在管理账号里面创建一个可信类型为阿里云账号的角色。然后他的授信策略可以被运维账号去扮演，这是第二步。

然后第三步，我们会在运维账号里面购买一台ECS，在这个ECS里面，我们会进行一些简单的操作，看看能否获取到这个主账号的临时AK，只要能够拿到这个临时AK，后面比如说您去调用阿里云的SDK、API，或者是跑Terraform，都可以继续进行。如果是在控制台的操作，我们大概会这样。然后我们已经将这个操作通过Terraform方案写成了一个程序。

那我们可以简单看一下，首先我们刚才讲的第一步，第一步是要在运维账号里面创建一个角色，并且要给它授权。这里面也写了，就是在这个步骤里面，会创建一个角色，同时会给它授权。

然后第二步，在这个MA账号里面，我们会在管理账号中创建一个自动化的角色，并完成相应的授权跟访问的授信策略。好，那我们就执行一下那个脚本。

我们稍微等一下。好，执行完了我们去看一下这个账号里面的资源是不是已经被创建出来了，当前的话是我们的管理账号，管理账号里面的话，我们刚才看到这个文档里面应该是说会创建一个角色，我们可以看一下这个角色是不是已经创建出来了。

大家可以看一下时间。这个是12点28分，就是刚刚创建出来的这个角色。然后这个角色里面的话，这个权限我们是给了他两个权限，一个是STS的权限，一个是管理资源目录的权限。然后它的授信策略的话是可以被这个463，463的话是我们的运维账号，被这个账号所扮演，权限跟授信策略都有了。脚本已经成功了。

然后我们现在进到这个运维账号里面去。运维账号里面其实我们刚刚看到这个步骤一里面，步骤一里面其实是也会创建一个角色，所以我们可以看一下这个运维账号里面这个角色是不是也创建出来了。我们叫ecs-role，这个时间也是我们刚刚创建的时间,然后我们可以看到这里面的这个权限有了，然后授信策略是ECS.

那说明我们刚刚执行完了这个Terraform脚本，已经把步骤一跟步骤二的这个资源创建好了，创建好了之后，接下来的话，我们在这个运维账号里面，我们有一台ECS。然后这个ECS里面要注意一点，就是说它要跟我们的这个角色要绑定。这个地方要稍微注意下，就是跟这个地方要有个绑定关系

因为如果不绑定的话，这个ECS是没有权限的。好，绑定完成后，接下来我们就开始在这个ECS上执行一些我们的阿里云的CLI的命令。阿里云CLI的话，大家可以在官网上查看它的手册，可以直接安装在ECS里面。我们可以把这几行代码都贴进去。

我们直接echo一下好了，我们可以把这个值echo出来看看。大家可以看到这个时候拿到的这个值，它其实是一个STS。就是一个临时的密钥。而这个临时的密钥，它其实是我们的管理账号的，资源管理账号就是我当前这个账号的临时密钥。所以如果说你拿到这个账号的这个密钥的话，它其实是可以操作这个账号里面的资源的，它的权限是比较大的，这样的话就实现了当我们的企业有多账号的时候，我们又有一个ops账号，它是专门做运维跟自动化相关的，那我可以在这里面买一台ECS，然后我所有的脚本都在这台ECS里面去做操作。在整个过程中，大家都没有看到一个明文的AK，都是通过这个临时的密钥来实现的，能够提升我们的安全性。那我这个实操的环节就演示到这里。

以上的话就是本期分享的全部内容。如果大家有任何疑问或者是关于云上自动化的想法，可以扫描下方的二维码，加入钉群，跟我们深入交流或联系我们。好，我们下期再见，谢谢大家。